Compose: docker-compose медленно на докере для бета-версии mac os

пинг @frenchben : улыбка:

+1

получил ту же проблему: D

@ smith64fx проблема тоже исчезнет, ​​если выключить WiFi?

@stijn Да, когда я выключаю Wi-Fi, все работает как шарм

Фон meinem iPhone gesendet

Am 05.05.2016 гм 00:26 schrieb Sebastiaan van Stijn [email protected] :

@ smith64fx проблема тоже исчезнет, ​​если выключить WiFi?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub

@ smith64fx Судя по вашей подписи, вы, скорее всего, из Германии (или Австрии / Швейцарии). Вы не против, чтобы я спросил, какой у вас интернет-провайдер? Мне интересно, есть ли у нас то же самое, и может ли он исходить из коробки, которая не выглядит как очень хорошее оборудование / программное обеспечение и не будет действовать так, как думал докер.

(Я работаю в Vodafone, и у меня есть их easybox - что угодно)

Та же проблема в проводной сети (корпоративной сети), как только я отключаю ее, все происходит очень быстро. Так что я уверен, что это не связано с вашим конкретным провайдером.

Я просмотрел подробный вывод, явных ошибок нет (ни в каких системных журналах). Хотя заметил это:

Без сети эти строки сгруппированы вместе:

docker attach <- (u'd90162cbfd7b312c28488a209440641b2d9c9f99e8eb59082f20ddf7d84e7b7e', stderr=True, stream=True, stdout=True)
docker attach -> <generator object _multiplexed_response_stream_helper at 0x1045f20a0>
docker start <- (u'd90162cbfd7b312c28488a209440641b2d9c9f99e8eb59082f20ddf7d84e7b7e')

Без сети я получаю ~ 100-200 строк 'compose.parallel.feed_queue: Pending: set ([])' между присоединением <- и тем местом, где он возвращается с присоединением -> ...

До этого момента с сетью происходит гораздо больше, но в основном это просто больше вызовов для проверки изображения и т.д.

Я приложил вывод команды compose --verbose up для ситуаций с ботами. Файл набора - это всего два контейнера прямо из хаба.

с -etwork.txt
без-network.txt

@holstvoogd о, хорошо для провайдера. Спасибо за информацию, немного волновался :)

@Erwyn @ smith64fx Чтобы подтвердить, что вы всегда подключены (жестко) и в то же время используете одну и ту же сеть с Wi-Fi?

@FrenchBen Нет, это только в сети Wi-Fi у меня дома. В моем офисе это очень быстро. Но дело в том, что все остальное дома работает быстро, кроме docker-compose ^ _ ^ "

@FrenchBen то же, что и @ smith64fx. Дома только Wi-Fi, поэтому проводного подключения нет. И, как я вижу, у @holstvoogd такая же проблема с проводным подключением.

Я замечаю ту же проблему с Docker для Mac Beta. docker-compose up работает медленно, когда Wi-Fi включен, быстро, когда Wi-Fi отключен.

• Версия Docker Compose: версия docker-compose 1.7.1, сборка 0a9ab35
• Версия Docker: версия Docker 1.11.1, сборка 5604cbe
• Версия ОС: OS X El Capitan 10.11.4

Привет, Есть какие-нибудь новости по этому поводу?

У меня такая же проблема. Версии Compose / Docker / OSX такие же, как у @eugenesia .
Я использую Wi-Fi дома и в офисе, а дома он работает очень медленно. В офисе работает как положено (быстро).

Я подумал, может быть, это что-то связано с DNS-сервером моего интернет-провайдера (домашние и офисные интернет-провайдеры разные), и я попытался использовать какой-то общедоступный DNS, включая Google, но это не помогло.

Если я отключу Wi-Fi, то docker-compose работает очень быстро

@KryDos На этой неделе должен выйти новый релиз с некоторыми улучшениями скорости

У меня такая же проблема, после обновления до докера для Mac 1.11.1-beta13 проблема не устранена. Обходной путь путем выключения и повторного включения сети (сетей) больше не работает, службы запускаются быстро при выключении сети, но при повторном включении сети службы больше не доступны, и демон докеров не отвечает.

docker ps
Error response from daemon: Bad response from Docker engine

• Версия Docker Compose: версия docker-compose 1.7.1, сборка 0a9ab35
• Версия Docker: версия Docker 1.11.1-beta13, сборка 7975
• Версия ОС: OS X El Capitan 10.11.5

У меня были те же проблемы, и я нашел сообщение (извините, потерял ссылку), в котором упоминается, что docker-compose пытается решить localunixsocket.local . Вы можете получить представление о поиске DNS, запустив sudo tcpdump -A -s0 -nni en0 port 53

На данный момент я указал localunixsocket.local на localhost в моем /etc/hosts . Теперь все снова быстро.

127.0.0.1 localunixsocket.local

Спасибо @jewilmeer , похоже, это полезно

Я снова переключился на виртуальный бокс с докер-машиной. Проблем не существует, и это до 10 раз быстрее, чем Docker Mac Beta!

@ smith64fx, пожалуйста,

супер классный комментарий, @jewilmeer! Мне пришлось добавить еще несколько адресов в / etc / hosts, которые я обнаружил с помощью вашей команды tcpdump :

# (yours)
127.0.0.1 localunixsocket.local
# additional ones -- be sure to replace bracketed thing with the output of `hostname`
127.0.0.1 localunixsocket.home <my hostname>.home

После этих дополнений - скорейшего! На самом деле, удивительно быстро, кажется, намного быстрее, чем при использовании Docker Toolbox! woop woop :) (Хотя это может быть очень субъективное наблюдение!)

Это довольно странно, но, похоже, указывает на основную проблему ...

В настоящее время у меня такая же проблема, и я не могу ее решить.
Я пробовал предыдущие предложения по редактированию /etc/hosts . В нашей офисной сети докер работает очень медленно. В домашних сетях или при использовании модема к мобильному телефону все замедляется, и все работает быстро.

Мы используем docker-compose с веб-контейнером, связанным с четырьмя сервисными контейнерами (postgres, redis, rabbitmq, elasticsearch). Можно подключиться к любому из четырех контейнеров служб напрямую из OSX. Медленно происходит только при попытке подключиться из веб-контейнера к любому из контейнеров служб.

Запуск tcpdump -vvv -s 0 -l -n port 53 дает следующий вывод при привязке к сотовому телефону

tcpdump: data link type PKTAP
tcpdump: listening on pktap, link-type PKTAP (Packet Tap), capture size 262144 bytes
16:54:34.236026 IP (tos 0x0, ttl 64, id 25341, offset 0, flags [none], proto UDP (17), length 69)
    172.20.10.4.56662 > 172.20.10.1.53: [udp sum ok] 5785+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:34.239617 IP (tos 0x0, ttl 64, id 29137, offset 0, flags [none], proto UDP (17), length 123)
    172.20.10.1.53 > 172.20.10.4.56662: [udp sum ok] 5785 NXDomain* q: PTR? 1.0.19.172.in-addr.arpa. 0/1/0 ns: 19.172.IN-ADDR.ARPA. [1d] SOA 19.172.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (95)
16:54:34.303325 IP (tos 0x0, ttl 64, id 46188, offset 0, flags [none], proto UDP (17), length 69)
    172.20.10.4.58590 > 172.20.10.1.53: [udp sum ok] 52066+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:34.309241 IP (tos 0x0, ttl 64, id 7329, offset 0, flags [none], proto UDP (17), length 123)
    172.20.10.1.53 > 172.20.10.4.58590: [udp sum ok] 52066 NXDomain* q: PTR? 1.0.19.172.in-addr.arpa. 0/1/0 ns: 19.172.IN-ADDR.ARPA. [1d] SOA 19.172.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (95)
16:54:39.309028 IP (tos 0x0, ttl 64, id 52570, offset 0, flags [none], proto UDP (17), length 69)
    172.20.10.4.63544 > 172.20.10.1.53: [udp sum ok] 12851+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:39.320135 IP (tos 0x0, ttl 64, id 32359, offset 0, flags [none], proto UDP (17), length 123)
    172.20.10.1.53 > 172.20.10.4.63544: [udp sum ok] 12851 NXDomain* q: PTR? 1.0.19.172.in-addr.arpa. 0/1/0 ns: 19.172.IN-ADDR.ARPA. [1d] SOA 19.172.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (95)
16:54:39.392915 IP (tos 0x0, ttl 64, id 8082, offset 0, flags [none], proto UDP (17), length 69)
    172.20.10.4.59994 > 172.20.10.1.53: [udp sum ok] 22334+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:39.416821 IP (tos 0x0, ttl 64, id 51863, offset 0, flags [none], proto UDP (17), length 123)
    172.20.10.1.53 > 172.20.10.4.59994: [udp sum ok] 22334 NXDomain* q: PTR? 1.0.19.172.in-addr.arpa. 0/1/0 ns: 19.172.IN-ADDR.ARPA. [1d] SOA 19.172.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (95)

и это результат при подключении к нашему офисному Wi-Fi:

16:54:13.870062 IP (tos 0x0, ttl 64, id 17811, offset 0, flags [none], proto UDP (17), length 69)
    192.168.0.32.56316 > 192.168.0.1.53: [udp sum ok] 21469+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:13.870723 IP (tos 0x0, ttl 64, id 53920, offset 0, flags [none], proto UDP (17), length 69)
    192.168.0.32.52082 > 192.168.0.1.53: [udp sum ok] 50601+ PTR? 1.0.19.172.in-addr.arpa. (41)
16:54:13.872706 IP (tos 0x0, ttl 64, id 50395, offset 0, flags [none], proto UDP (17), length 69)
    192.168.0.32.56176 > 192.168.0.1.53: [udp sum ok] 45180+ PTR? 1.0.19.172.in-addr.arpa. (41)

Так что это похоже на обратный поиск DNS, но я не знаю, как устранить неполадки. Отключение Wi-Fi полностью гарантирует и эту медлительность. Отключение и повторное включение не помогает.

Конечно, вы найдете собственное решение сразу после того, как разместите вопрос. Похоже, что установленный пакет в нашей среде разработки обновил настройки DNS в OSX, которые вызывают проблему. После того, как я сбросил OSX DNS на значения по умолчанию в /etc/resolv.conf, все заработало.

Может ли это быть связано с тем, что Bonjour «владеет» .local и ошибкой IPV6?
подробности: https://news.ycombinator.com/item?id=11567442

Не знаю, помогает ли это, но раньше у меня была эта проблема, и я исправил ее, изменив свои DNS-серверы на 8.8.8.8 и 8.8.4.4 .

Также эта проблема возникла только в моей домашней сети. На работе у меня не было этого вопроса.

Я также сталкиваюсь с той же проблемой даже после попытки исправить @jewilmeer .
docker-compose up отлично работает в моей офисной сети, но в моей домашней сети это занимает около 7 минут.
такое же поведение с другими командами docker-compose, такими как stop, pull, ps и т. д.

docker --version
Докер версии 1.12.0-rc2, сборка 906eacd, экспериментальная

docker-compose --version
docker-compose версия 1.8.0-rc1, сборка 9bf6bc6

докер-машина - версия
docker-machine версия 0.8.0-rc1, сборка fffa6c9

Не знаю почему, но мне пришлось удалить любой элемент локального домена, чтобы он заработал.

/ etc / hosts:
127.0.0.1 localunixsocket

У меня очень похожая проблема, но я думаю, она может быть связана с тем, что я использую DNSCrypt ?

@Erwyn У меня такая же проблема с Vodafone Easybox ...
оказалось, что Vodafone Easybox привязывает поиск доменов .local к роутеру (для оценки динамического имени хоста вашего роутера, а именно easy.box )
и я предполагаю, что эта привязка заставляла docker-compose ждать ответа маршрутизатора (я могу быть совершенно неправ в этом) ...
но добавление
127.0.0.1 localunixsocket.local to etc/hosts решил проблему за меня

Привет, ребята,
127.0.0.1 localunixsocket to etc / hosts решили проблему за меня

@davidino Thx Bro, отлично работает! Меня интересует, зачем нам этот обходной путь?

Привет ребята! Здесь та же проблема. В Бразилии использование Wi-Fi в офисе занимает много времени. После изменения файлов /etc/hosts все

Здесь та же проблема. Работа из одного офиса (по WIFI) проблем и задержек у меня нет. Работая в другом офисе (тоже по WIFI), я получал ~ 10 минут задержки.

Добавление 127.0.0.1 localunixsocket в /etc/hosts _не_ решило проблему для меня. Я попытался сделать это в сочетании с перезагрузкой, но все равно не повезло.

Добавление 8.8.8.8 и 8.8.4.4 качестве DNS-серверов решило проблему.

Спасибо, @Typositoire!

Привет, @dadarek , попробуй добавить 127.0.0.1 localunixsocket.home <hostname>.home в свой файл hosts. У меня это сработало, когда я добавил оба имени хоста. Таким образом, вы все еще можете использовать свой локальный DNS, если вам нужно ...

Это происходит для меня как на стабильном, так и на бета-канале, отключение Интернета или добавление записи хоста исправляет это для меня.

Эль-Капитан 10.11.4
Докер версии 1.12.0, сборка 8eab29e, экспериментальная
docker-compose версия 1.8.0, сборка f3628c7
докер-машина версии 0.8.0, сборка b85aac1

Я попробовал и имя хоста, и отключение интернета с помощью команды сборки, и ничего не помогло ... попробовал изменить DNS ... он просто сидит там 5-10 минут, а затем запускает процесс сборки ... Я вижу, что загрузка процессора идет до 100% в процессе создания докеров

http://i.imgur.com/fmlhjCo.png

так расстраивает

http://i.imgur.com/C1P6zHi.png

кстати установка отлично работала с набором инструментов и работала очень быстро ...

с подробной отладкой я вижу, что он висит здесь

[home / docker] - приложение $ docker-compose --verbose build

compose.config.config.find: Использование файлов конфигурации: ./docker-compose.yml
docker.auth.auth.load_config: файл не существует
compose.cli.command.get_client: docker-compose версия 1.8.0, сборка f3628c7
версия docker-py: 1.9.0
Версия CPython: 2.7.9
Версия OpenSSL: OpenSSL 1.0.2h 3 мая 2016 г.
compose.cli.command.get_client: Docker base_url: http + docker: // localunixsocket
compose.cli.command.get_client: Версия Docker: KernelVersion = 4.4.15-moby, Os = linux, BuildTime = 2016-07-28T21: 15: 28.963402499 + 00:00, ApiVersion = 1.24, Version = 1.12.0, GitCommit = 8eab29e, Arch = amd64, GoVersion = go1.6.3
compose.service.build: Создание приложения
compose.cli.verbose_proxy.proxy_callable: docker build <- (pull = False, stream = True, nocache = False, tag = u'docker_app ', buildargs = None, rm = True, forcerm = False, path =' / Users / bartdabek / Sites / docker ', dockerfile =' Dockerfile-app ')

через несколько минут он переходит в

docker.api.build._set_auth_headers: Ищем конфигурацию аутентификации
docker.api.build._set_auth_headers: нет конфигурации аутентификации в памяти - загрузка из файловой системы
docker.auth.auth.load_config: файл не существует
docker.api.build._set_auth_headers: конфигурация аутентификации не найдена

потом опять зависает ...

моя скорость интернета в порядке, только что проверил на 60 МБ / с

включение Exclude simple hostnames настройках прокси у меня отлично сработало.

NO_PROXY=* docker-compose up

Обходной путь, опубликованный @jewilmeer
https://github.com/docker/compose/issues/3419#issuecomment -221793401 у меня работает.

Было бы хорошо получить подсказку от @jibingeo в Docker для Mac на README.md или где-нибудь в учебнике.

Привет, ребята, @thaJeztah.

После просмотра исходного кода я обнаружил, что socket.gethostbyname("localunixsocket") выполняется более 30 секунд (в моем случае).

Итак, я запросил свой локальный DNS и Google DNS.

$ time nslookup localunixsocket 10.0.0.1
Server:     10.0.0.1
Address:    10.0.0.1#53

** server can't find localunixsocket: NXDOMAIN

real    0m30.295s
user    0m0.004s
sys     0m0.005s

$ time nslookup localunixsocket 8.8.8.8
Server:     8.8.8.8
Address:    8.8.8.8#53

** server can't find localunixsocket: NXDOMAIN

real    0m0.685s
user    0m0.005s
sys     0m0.013s

Локальный DNS отлично работает с именем хоста FQDN

time nslookup google.com 10.0.0.1
Server:     10.0.0.1
Address:    10.0.0.1#53

Non-authoritative answer:
Name:   google.com
Address: 216.58.196.110


real    0m0.028s
user    0m0.005s
sys 0m0.006s

Это означает, что актуальная проблема связана с DNS маршрутизатора.

Это только мне кажется, или поиск в DNS для localunixsocket кажется нелогичным? Это похоже на имя хоста-заполнителя, которое просто используется в качестве заполнителя, когда что-то ожидает адреса в стиле TCP вместо сокетов локального домена.

В любом случае, разница во времени между локальным DNS и DNS Google интересна ... Мне было бы любопытно, что заставляет его это делать. (к сожалению, я думаю, вам понадобится еще один дамп TCP на DNS-сервере, на который указывает маршрутизатор, чтобы сказать, если нет эквивалента tracert для поиска DNS, который может сохранить промежуточные серверы, пораженные рекурсивным запрос)

Это также может быть информативным (находится в man nslookup в Mac OS X):

УВЕДОМЛЕНИЕ о Mac OS X

Команда nslookup не использует имя хоста и разрешение адреса
или механизмы маршрутизации запросов DNS, используемые другими процессами, запущенными на
Mac OS X. Результаты запросов на имя или адрес, напечатанные nslookup
могут отличаться от результатов, найденных другими процессами, использующими Mac OS X
собственные механизмы разрешения имен и адресов. Результаты DNS
запросы также могут отличаться от запросов, использующих DNS-маршрутизацию Mac OS X
библиотека.

Поскольку они на самом деле не дают никаких разъяснений относительно того, какой конкретный механизм использует nslookup _does_ по сравнению с тем, что предоставляет Mac OS X, трудно сказать, будет ли Docker разделять поведение nslookup , или других приложений Mac OS X ... (я предполагаю, что он использует те же методы, что и nslookup , но нам, вероятно, придется копаться в коде для обоих, чтобы окончательно понять это)

Привет @whitingnx

Вот дамп TCP, полученный с помощью Local DNS и Google DNS. Команда, которую я использовал для получения дампа:

sudo killall -HUP mDNSResponder && docker-compose ps

С локальным DNS:

15:49:30.025038 IP (tos 0x0, ttl 255, id 18504, offset 0, flags [none], proto UDP (17), length 83)
    10.0.0.3.60707 > 10.0.0.1.53: [udp sum ok] 54235+ PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
15:49:30.291508 IP (tos 0x0, ttl 255, id 36848, offset 0, flags [none], proto UDP (17), length 61)
    10.0.0.3.52331 > 10.0.0.1.53: [udp sum ok] 10799+ A? localunixsocket. (33)
15:49:31.097658 IP (tos 0x0, ttl 255, id 32568, offset 0, flags [none], proto UDP (17), length 83)
    10.0.0.3.60707 > 10.0.0.1.53: [udp sum ok] 54235+ PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
15:49:31.368098 IP (tos 0x0, ttl 255, id 54970, offset 0, flags [none], proto UDP (17), length 61)
    10.0.0.3.52331 > 10.0.0.1.53: [udp sum ok] 10799+ A? localunixsocket. (33)
15:49:33.596367 IP (tos 0x0, ttl 30, id 20508, offset 0, flags [none], proto UDP (17), length 133)
    10.0.0.1.53 > 10.0.0.3.60707: [udp sum ok] 54235 NXDomain* q: PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. 0/1/0 ns: 10.IN-ADDR.ARPA. [1d] SOA 10.IN-ADDR.ARPA. . 0 28800 7200 604800 86400 (105)
15:49:33.597103 IP (tos 0x0, ttl 30, id 20510, offset 0, flags [none], proto UDP (17), length 136)
    10.0.0.1.53 > 10.0.0.3.52331: [udp sum ok] 10799 NXDomain q: A? localunixsocket. 0/1/0 ns: . [2h8m4s] SOA a.root-servers.net. nstld.verisign-grs.com. 2016090900 1800 900 604800 86400 (108)

С Google DNS:

15:45:25.301293 IP (tos 0x0, ttl 255, id 37492, offset 0, flags [none], proto UDP (17), length 83)
    10.0.0.3.60707 > 8.8.8.8.53: [udp sum ok] 14029+ PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. (55)
15:45:25.371167 IP (tos 0x0, ttl 56, id 10269, offset 0, flags [none], proto UDP (17), length 83)
    8.8.8.8.53 > 10.0.0.3.60707: [udp sum ok] 14029 NXDomain q: PTR? lb._dns-sd._udp.0.0.0.10.in-addr.arpa. 0/0/0 (55)
15:45:25.599570 IP (tos 0x0, ttl 255, id 7256, offset 0, flags [none], proto UDP (17), length 61)
    10.0.0.3.59912 > 8.8.8.8.53: [udp sum ok] 3154+ A? localunixsocket. (33)
15:45:25.702374 IP (tos 0x0, ttl 56, id 39895, offset 0, flags [none], proto UDP (17), length 136)
    8.8.8.8.53 > 10.0.0.3.59912: [udp sum ok] 3154 NXDomain q: A? localunixsocket. 0/1/0 ns: . [29m58s] SOA a.root-servers.net. nstld.verisign-grs.com. 2016090900 1800 900 604800 86400 (108)

Здесь я вижу задержку ~ 3 секунды с локальным DNS.

Примечание. Маршрутизатор, который я использовал здесь, отличается от того, который я использовал для предыдущего комментария.

Привет всем,
после обновления до докера для Mac Version 1.12.1 (build: 12133) мне пришлось добавить
127.0.0.1 localunixsocket снова в /etc/hosts

Я должен был сделать то же самое, что и Давидино.

Нет оценок по устранению этой очень надоедливой ошибки?

Мне просто нужно было добавить 127.0.0.1 localunixsocket.lan чтобы он заработал. Я использую macOS Sierra.

Я действительно не знаю, такая же проблема, но ответ @jibingeo мне помог.
_docker-compose_ также очень медленно работает в среде моей компании с использованием Docker Toolbox для Windows. Мне тоже помогла настройка NO_PROXY=* , но это мешает работе прокси моей компании. Итак, я немного попробовал и нашел более конкретное решение (при условии, что вы используете диапазон IP-адресов VirtualBox по умолчанию 192.168.99.0/24):

NO_PROXY=192.168.99.0/24 все ускоряет, поэтому Compose не нужно пробовать прокси моей компании для внутренних IP-адресов.

Связанный? https://github.com/SeleniumHQ/docker-selenium/issues/227

Решение @davidino по добавлению 127.0.0.1 localunixsocket в /etc/hosts решило проблему для меня.

Теперь намного быстрее

У меня такие же проблемы. Я попытался отключить Wi-Fi, добавив несколько записей в файл хоста, но безуспешно. Я пробовал ту же настройку на своем Linux-боксе, и результаты стали намного быстрее.

Кажется, что сборка выполняется с приличной скоростью, но как только я делаю какие-либо запросы в работающие контейнеры, результат ужасен. Около 30 секунд на любой запрос, даже если это простой текстовый ответ.

Я использую Mac OS Sierra (10.12.1) и Docker для Mac (1.12.1) со стеком Rails.

Я на 10.11.6 (15G31)

Вот что находится в моем файле /etc/hosts :

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
255.255.255.255 broadcasthost
::1             localhost 
127.0.0.1 localhost
127.0.0.1 localunixsocket
127.0.0.1 localunixsocket.lan
127.0.0.1 localunixsocket.local

Я нахожусь на докере бета-канала 1.12.3-beta29.2 (13499)

@gardner Я добавил это в свой файл hosts и безуспешно пробовал бета-версию. Я действительно начинаю думать, что это как-то связано с Сьеррой. Я почти уверен, что он работал до того, как я обновился. Я собираюсь еще раз попробовать бета-версию, чтобы посмотреть, работает ли она. Я отправлю еще раз после тестирования.

@gardner Та же проблема. Сейчас работает Docker 1.12.3-beta29.3 (13640). Моя установка Linux по-прежнему работает намного быстрее с 1/4 RAM.

Лучшее, что я могу сказать, это то, что это проблема ввода-вывода между докером и хост-машиной. Я запустил флеймеграф по запросу, и большую часть времени он тратит на чтение файлов.
https://www.dropbox.com/s/4702tx7qqpkr4yd/Screenshot%202016-11-02%2014.39.22.png?dl=0

Это то же приложение, тот же запрос, работающий локально.
https://www.dropbox.com/s/xxs5jdug7cllpbu/Screenshot%202016-11-02%2014.44.37.png?dl=0

Если я настрою приложение для работы в производственном режиме, оно будет работать так же быстро внутри Docker.

Не уверен, известно ли это уже или нет, но, надеюсь, это поможет любому, кто зайдет в эту ветку, пытаясь понять это.

Изменить: похоже, это настоящая проблема, с которой я сталкиваюсь. https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/223

Также сталкиваясь с этой проблемой, изменения в хостах немного меняют, но все же немного медленнее.
127.0.0.1 localunixsocket.local 127.0.0.1 localunixsocket

Я вижу это в следующей стабильной версии докера под управлением OSX 10.11.6 со следующей версией докера:

Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 23:26:11 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 23:26:11 2016
 OS/Arch:      linux/amd64

Я вижу это при медленном подключении к облаку (Облако в кафе в Лондоне), когда я выключаю Wi-Fi, создание текста происходит очень быстро, в противном случае все работает очень медленно ...

Похоже, что последняя версия (1.9.0) что-то изменила для людей, столкнувшихся с проблемой?

@ shin - У меня все еще 1.8.1 в моем docker-compose --version с последней версией Docker для Mac. Когда нам ждать обновления?

Когда можно ожидать решения этой проблемы?

1.9 находится в стадии бета-тестирования, не уверен, когда он выйдет в стабильной версии, возможно
через неделю или около того.

18 ноября 2016 г. в 8:07 «Дэвид Ричардс» [email protected] написал:

@ shin- https://github.com/shin- У меня все еще есть версия 1.8.1 в моем docker-compose
- версия с последней версией Docker для Mac. Когда нам ждать обновления?

-
Вы получили это, потому что оставили комментарий.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/docker/compose/issues/3419#issuecomment-261472095 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAdcPBV7gMv0kMwil0SEz3etChNY6ej3ks5q_VyugaJpZM4IXnGd
.

Для меня McAfee Endpoint Security был причиной того, что docker-compose был очень медленным. Похоже, что сканер при доступе действительно убивает производительность распаковки среды Python, которая, кажется, происходит каждый раз, когда выполняется docker-compose.

Для меня удаление домена поиска .local имело решающее значение.

@ shin- в 1.9.0-rc4 меня все еще проблема. Я не знаю, что я сделал, но несколько дней назад у меня не было проблемы, я использовал docker-compose более года.
docker-compose --version действительно быстро
docker-compose ps очень медленный
Отключение Wi-Fi - ps тоже быстро

@gsong, к сожалению, мне это не помогло

У меня тоже внезапно возникла эта проблема. Как и @timuchanek, я использую docker-compose около года, и docker-compose up зависает почти бесконечно. Как и у всех, при выключении wifi работает.

Я на docker-compose version 1.9.0, build 2585387

Изменить: добавление 127.0.0.1 localunixsocket к /etc/hosts исправлено. Я использую macOS 10.11.6

Каковы шансы, что это связано с изменениями .local внесенными в yosemite?

https://support.apple.com/en-us/HT203136
https://news.ycombinator.com/item?id=9026192

Я видел, что @afxjzs упоминал об этом ранее, но не видел никаких последующих действий .

Я наткнулся на то, что у меня работает, пытаясь заставить работать xdebug:

sudo ifconfig en0 alias 10.254.254.254 255.255.255.0

на хост-машине.

Спасибо Джеймсу Коуи .

Изменить: похоже, что xdebug был корнем моей проблемы. Когда xdebug выключен, моя докер-машина работает очень быстро, даже если / etc / hosts находится в состоянии по умолчанию. Когда он включен и мой xdebug.remote_host установлен на 10.254.254.254, он замедляется до сканирования. Предлагаемые изменения в / etc / hosts не помогают, но установка псевдонима localhost на en0, как указано выше, решает проблему.

Это происходит со мной с последним стабильным Docker для Mac (1.13.1, docker-compose 1.11.1)

Выполнение NO_PROXY=* работает.

Это случилось со мной и с последним обновлением (1.13.1, docker-compose 1.11.1). https://github.com/docker/compose/issues/3419#issuecomment -221793401 решил мою проблему.

У меня такая же ошибка. Добавление localunixsocket в /etc/hosts . не работало. Временное исправление отметки Exclude simple hostnames на вкладке прокси.

macOS Sierra 10.12.3 (16D32)
Docker version 1.13.1, build 092cba3
docker-compose version 1.11.1, build 7c5d5e4

Я заметил, что любые невосприимчивые поисковые домены очень медленно создают докеры. Это не просто .local Я использовал .dev .

Сегодня я столкнулся с той же проблемой, когда docker-compose зависает вечно даже для отображения справки или --version. Я последовал совету @jewilmeer по использованию tcpdump, и в моем случае проблема была решена путем добавления 127.0.0.1 prod.python.map.fastly.net к хостам / etc

Думаю, довольно странно?

Здесь та же проблема. Похоже, зависает дважды, каждый примерно по 25 секунд. Вот результат --verbose с каждым вставленным HANG

compose.config.config.find: Using configuration files: ./config/docker-compose-dev.yml
docker.auth.find_config_file: Trying paths: ['/Users/dorkusprime/.docker/config.json', '/Users/dorkusprime/.dockercfg']
docker.auth.find_config_file: Found file at path: /Users/dorkusprime/.docker/config.json
docker.auth.load_config: Found 'auths' section
docker.auth.parse_auth: Found entry (registry=u'https://index.docker.io/v1/', username=u'dorkusprime')

[HANGS FOR ~25S]

compose.cli.command.get_client: docker-compose version 1.11.2, build dfed245
docker-py version: 2.1.0
CPython version: 2.7.12
OpenSSL version: OpenSSL 1.0.2j  26 Sep 2016
compose.cli.command.get_client: Docker base_url: http+docker://localunixsocket
compose.cli.command.get_client: Docker version: KernelVersion=4.9.13-moby, Arch=amd64, BuildTime=2017-03-15T20:28:18.193664702+00:00, ApiVersion=1.27, Version=17.03.1-ce-rc1, MinAPIVersion=1.12, GitCommit=3476dbf, Os=linux, Experimental=True, GoVersion=go1.7.5
compose.project.build: mongodb uses an image, skipping
compose.project.build: redis uses an image, skipping
compose.service.build: Building web
compose.cli.verbose_proxy.proxy_callable: docker build <- (pull=False, stream=True, nocache=False, tag='dorkusprime/dashboard-test', buildargs=None, rm=True, forcerm=False, path='/Users/dorkusprime/repository/Dashboard-test', dockerfile=None)
docker.api.build._set_auth_headers: Looking for auth config
docker.api.build._set_auth_headers: Sending auth config (u'https://index.docker.io/v1/')

[HANGS FOR ~25S]

compose.cli.verbose_proxy.proxy_callable: docker build -> <generator object _stream_helper at 0x105cc4910>

Я пробовал обходные пути / etc / hosts без заметных улучшений.

Здесь та же проблема, и никакое решение из всего потока мне не помогает (ни /etc/hosts ни переменная NO_PROXY ни Exclude simple hostnames ни изменение DNS на 8.8.8.8 ).

Одно замечание: если я запускаю докер с sudo, это решает проблему скорости.

Последняя версия докера (версия Docker 17.03.1-ce-rc1, сборка 3476dbf). Пробовал как бета-версию, так и стабильную.

docker --version в моем случае выводит версию за 32 секунды.

Эта проблема существует уже почти год ...

@mobileka Вы говорите о docker или docker-compose ?

@ shin - В моем случае каждая команда cli (будь то docker или docker-compose ), связанная с докером, имеет задержку около 30 секунд до фактического получения результатов или до начала выполнения своей работы.

@mobileka Хорошо - это определенно не связано с проблемой, описанной здесь. Вместо этого рассмотрите возможность создания проблемы в репозитории Docker для Mac .

@ shin- Извините, я не понял, что нахожусь в неправильном репо, потому что «симптомы» были очень похожи: он медленный, когда подключение к Интернету активно, и быстро, когда нет подключения к Интернету.

Спасибо, я создам проблему в репозитории Docker для Mac.

На случай, если это коснется кого-то еще, я почти уверен, что мои эксперименты (и последующие неудачи) с Consul добавили файл конфигурации в / etc / resolvers. Это вызвало проблемы, похожие на @seeekr, о , вот так:

A.D.*.5.>t.d............localunixsocket.foo.bar.example.com.....
14:36:13.357925 IP 10.23.45.67.65066 > 10.98.76.54.53: 25754+ A? localunixsocket.foo.bar.example.com. (54)
E..R.......P
...

Удаление файла из / etc / resolvers сразу решило проблему.

Надеюсь, это поможет!

Здесь та же проблема, и никакое решение из всего потока мне не помогает (ни / etc / hosts, ни переменная NO_PROXY, ни Exclude simple hostnames, ни изменение DNS на 8.8.8.8).

Я пишу игрушечный веб-сайт (логика действительно простая и не должно иметь проблем с производительностью) и запускаю его локально с помощью docker-compose. Оказывается, загрузка почти каждой страницы занимает минуты. Есть инструкция?

Время загрузки страницы

MacOS Sierra, 10.12.5.
Docker Community Edition
Версия 17.06.0-ce-mac18 (18433)
Канал: стабильный
d9b66511e0

У меня уже был DNS как 8.8.8.8. Необходимо добавить как localunixsocket.local, так и localunixsocket в / etc / hosts. В тот момент, когда это было добавлено, моя работающая программа docker-compose ожила.

Я не уверен, поможет ли это кому-нибудь, но у меня установлен dnscrypt, и после перехода на бета-версию docker создание докеров было невероятно медленным. Переустановка dnscrypt (через brew cask) устранила проблему для меня.

Я люблю тебя @jewilmeer

Просто хотел оставить это здесь. Мои проблемы заключались в файлах сеанса внутри моего контекста сборки. Файлы принадлежали пользователю apache, и сборка docker-compose просто зависала после этой строки:

docker.api.build._set_auth_headers: No auth config found 

Самое печальное, что я давно перестал использовать файловые сессии. Вероятно, мне следует время от времени чистить мое рабочее место.

Причина комментария: Было бы здорово, если бы compose просто не зависал. Я обнаружил виновника только напрямую, используя сборку докеров, которая хорошо проинформировала меня о моих проблемах.

@paali, можешь

@ Vad1mo, моя полная настройка довольно сложна (и грязна и в процессе), но основные части - это проект Symfony2. Были старые файлы сеанса в папке ./app/sessions, которые принадлежали пользователю apache (до времени докеров).

В основном у меня было
COPY app app/
один из файлов Dockerfiles и docker-compose.yml для создания необходимого файла Dockerfile.
Используемая команда:
docker-compose -f docker-compose-ci.yml build --no-cache --force-rm

Как уже отмечалось, процесс сборки на самом деле так и не начался, а завис после строк о заголовках auth. Сборка на докере напрямую дала мне:

> docker build -f thefile --no-cache --force-rm
error checking context: 'no permission to read from '/path/to/my/project/app/sessions/sess_n8turtujft1bipv745khqsqbi1''.

В следующий раз я сразу пойму, что нужно попробовать докер, но на самом деле ничего не подсказывало, в чем была настоящая проблема. Я использую Docker для Mac 7.06.1-ce-mac24.

Есть ли хоть слово о реальном решении этой проблемы, кроме необходимости сказать всем, чтобы они добавили правило хоста или отключили прокси?

+1

+1

+1

Что исправило для меня, так это переход в мои Системные настройки / Сеть / Расширенный / DNS / Поисковые домены и удаление записи «.local». который я положил туда. Это заставило macOS заполнить поисковые домены только значением по умолчанию «localdomain». А потом docker-compose снова стал отзывчивым.

Сам docker все время реагировал.

Я не знаю, но я предполагаю, что, возможно, docker правильно находит ресурс в системе, используя IP-адрес или стабильное локальное имя, в то время как docker-compose небезопасно полагается на localdomain всегда определяется как один из поисковых доменов. Но я не знаю!

Я бы запустил строку для мониторинга DNS, которая была в исходном сообщении об исправлении:

sudo tcpdump -A -s0 -nni en0 порт 53

Это показало мне, что мне нужно добавить в свой хост-файл:

127.0.0.1 localunixsocket.localdomain

кажется, что-то изменилось с .local на .localdomain?

С тех пор я сделал новую установку 10.12 Sierra. Я переустановил докер и не смог воспроизвести проблему.

Я столкнулся с этой проблемой сегодня, в свой первый день работы на Mac.
Docker compose просто застопорился, буквально после вставки строки в /etc/hosts он начал работать должным образом.
Я использовал Wi-Fi , все в офисе с одной и той же версией Ethernet даже не слышали об этой проблеме.
Докер: Version 17.09.0-ce-mac35 (19611)
Mac 10.13.1 (17B48)

Здесь та же ошибка. Я должен добавить три строки в / etc / hosts, чтобы решить эту проблему.
127.0.0.1 localunixsocket
127.0.0.1 localunixsocket.lan
127.0.0.1 localunixsocket.local

Та же ошибка. Это сработало для меня.

$ sudo tcpdump -vvv -s 0 -l -n port 53
...
13:46:10.203734 IP (tos 0x0, ttl 255, id 7224, offset 0, flags [none], proto UDP (17), length 81, bad cksum 0 (->7b21)!)
    10.64.14.244.54683 > 10.0.0.10.53: [bad udp cksum 0x2491 -> 0xf39b!] 30038+ A? localunixsocket.*.svc.cluster.local. (53)

$ sudo vim /etc/hosts

# hacks for docker
127.0.0.1 localunixsocket.*.svc.cluster.local

Я добавил 127.0.0.1 localunixsocket в /etc/hosts и у меня это сработало, спасибо!
(но это все еще ошибка wtf)

По-прежнему проблема в последней версии. Вышеупомянутые исправления, похоже, ничего не делают для меня, в какой-то момент он просто становится настолько медленным, что зависает. Для меня обходной путь - периодически перезапускать Docker для Mac.

Подтверждено, что 127.0.0.1 localunixsocket в /etc/hosts значительно ускоряет работу, пожалуйста, исправьте!

добавление 127.0.0.1 localunixsocket в /etc/hosts помогает. Я использую docker-compose version 1.18.0, build 8dd22a9

Решение, рекомендованное @norbertsienkiewicz, у меня отлично сработало. Это снизило мое docker-compose up время с более 10 минут до менее чем минуты (версия 1.18.0).

Мне на самом деле более любопытно, почему это вообще началось. Мне кажется немного глупым, что мне приходится изменять мой файл hosts в качестве обходного пути к проблеме, которая была недавно представлена ​​и объявлена ​​«решением».

Вот обратная трассировка, которая вызывает ложный поиск в DNS:

  File "/Library/Python/2.7/site-packages/docker-3.1.0-py2.7.egg/docker/api/daemon.py", line 88, in info
    return self._result(self._get(self._url("/info")), True)
  File "/Library/Python/2.7/site-packages/docker-3.1.0-py2.7.egg/docker/utils/decorators.py", line 46, in inner
    return f(self, *args, **kwargs)
  File "/Library/Python/2.7/site-packages/docker-3.1.0-py2.7.egg/docker/api/client.py", line 193, in _get
    return self.get(url, **self._set_request_timeout(kwargs))
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/sessions.py", line 521, in get
    return self.request('GET', url, **kwargs)
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/sessions.py", line 499, in request
    prep.url, proxies, stream, verify, cert
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/sessions.py", line 672, in merge_environment_settings
    env_proxies = get_environ_proxies(url, no_proxy=no_proxy)
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/utils.py", line 692, in get_environ_proxies
    if should_bypass_proxies(url, no_proxy=no_proxy):
  File "/Library/Python/2.7/site-packages/requests-2.18.4-py2.7.egg/requests/utils.py", line 676, in should_bypass_proxies
    bypass = proxy_bypass(netloc)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib.py", line 1487, in proxy_bypass
    return proxy_bypass_macosx_sysconf(host)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib.py", line 1453, in proxy_bypass_macosx_sysconf
    hostIP = socket.gethostbyname(hostonly)

У меня возникла эта проблема после переключения с беспроводной связи на проводную. Вернемся к беспроводной связи, и все в мире в порядке.

Изменения в / etc / host касаются хост-машины или контейнера докеров?

Какой файл hosts изменить?

1. macOS hosts файл?
2. Виртуальная машина Linux, выступающая в качестве узла докеров?
3. Сам контейнер?

Не знаю почему, но мне пришлось удалить любой элемент локального домена, чтобы он заработал.

/ etc / hosts:
127.0.0.1 localunixsocket

Гений !!!