Compose: docker-compose on docker for mac os beta缓慢

ping @frenchben ：微笑：

+1

有同样的问题：D

如果您关闭WiFi， @ smith64fx问题也消失了吗？

@stijn是的，当我关闭wifi时，所有功能都像魅力一样

冯·梅涅姆iPhone gesendet

上午05.05.2016下午00:26 schrieb Sebastiaan van Stijn [email protected] ：

如果您关闭WiFi， @ smith64fx问题也消失了吗？

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件或在GitHub上查看

@ smith64fx我从您的签名中看到您很可能来自德国（或奥地利/瑞士）。 您介意我问您的互联网提供商是什么？ 我想知道我们是否具有相同的功能，以及它是否可能来自包装盒，看起来不像是很好的硬件/软件，并且不会像docker那样发挥作用。

（我在沃达丰（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：待定：set（[]）'。

在此之前，网络也发生了很多事情，但是看起来似乎只有更多的电话需要检查图像。

我已经将compose --verbose的输出附加到了bot情况中。 撰写文件只是离集线器不远的两个容器。

with-networking.txt
没有网络.txt

@holstvoogd哦，提供者还可以。 感谢您提供的信息，我有点担心:)

@Erwyn @ smith64fx要确认，您始终保持连接（硬连线），并且同时使用具有wifi的同一网络？

@FrenchBen不，它仅在我家的wifi网络中。 在我的办公室，速度非常快。 但问题是，除了docker-compose ^ _ ^“以外，其他一切都运行得很快

@FrenchBen与@ smith64fx相同。 这是家里唯一的wifi，因此不涉及有线连接。 正如我所看到的， @ holstvoogd似乎在有线连接方面存在相同的问题。

我注意到Docker for Mac Beta出现了同样的问题。 启用Wifi时， docker-compose up较慢，而禁用Wifi时，

• 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相同。
我在家里和办公室都使用WiFi，而在家里，它的工作速度却异常缓慢。 在办公室，它可以按预期工作（快速）。

我以为这可能与我的ISP的DNS服务器有关（家庭和办公室互联网提供商有所不同），我尝试使用一些公共DNS，包括Google的DNS，但这没有帮助。

如果我关闭WiFi，则docker-compose运行速度非常快

@KryDos本周应发布新版本，并在速度上有所改进

我有相同的问题，对于Mac 1.11.1-beta13更新到docker后，问题仍然存在。 通过关闭网络然后重新启动的解决方法不再起作用，关闭网络时服务会快速启动，但是当再次打开网络时，服务将不再可访问并且docker守护程序没有响应

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 。 您可以通过运行sudo tcpdump -A -s0 -nni en0 port 53深入了解dns查找

现在，我已经将localunixsocket.local指向我的/etc/hosts localhost。 现在一切都很快了。

127.0.0.1 localunixsocket.local

谢谢@jewilmeer ，这看起来很有用

我在docker-machine上使用virtualbox切换回去。 问题不存在，它比Docker Mac Beta快10倍！

@ 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快很多！ 哇！:)（尽管这可能是一个非常主观的观察！）

这很奇怪，但似乎指出了潜在的问题是什么...

我目前也面临同样的问题，但无法解决。
我已经尝试过编辑/etc/hosts的先前建议。 在我们的办公室网络中，docker非常慢。 在家庭网络上或使用网络绑定到手机，可以消除所有速度变慢的情况，而且一切都很迅速。

我们将docker-compose与一个链接到四个服务容器（postgres，redis，rabbitmq，elasticsearch）的Web容器一起使用。 直接从OSX连接到四个服务容器中的任何一个都可以。 仅在尝试从Web容器连接到任何服务容器时，速度很慢。

绑定到手机时，运行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)

这是在我们办公室wifi上的输出：

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查找的内容，但是我不确定如何进行故障排除。 完全禁用wifi也会确保这种缓慢性。 禁用和重新启用没有帮助。

当然，发布问题后，您会找到自己的解决方案。 看起来像是我们开发环境中的已安装软件包已更新OSX中的DNS设置，这导致了问题。 一旦我将OSX DNS重置为使用/etc/resolv.conf中的默认值，一切都会正常。

这可能与Bonjour“拥有” .local和IPV6错误有关吗？
详细信息： https :

Dunno如果有帮助，但是我曾经遇到这个问题，并通过将DNS服务器更改为8.8.8.8和8.8.4.4 。

同样，此问题仅发生在我的家庭网络上。 在工作中我没有这个问题。

即使尝试了@jewilmeer的修复程序，我也面临着同样的问题。
docker-compose up在我的办公室网络上工作正常，但是在我的家庭网络上大约需要7分钟。
与其他docker-compose命令（如stop，pull，ps等）具有相同的行为。

码头工人-版本
Docker版本1.12.0-rc2，内部版本906eacd，实验性

docker-compose --version
docker-compose版本1.8.0-rc1，内部版本9bf6bc6

docker-machine --version
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到etc/hosts为我解决了这个问题

嗨，大家好，
127.0.0.1 localunixsocket到etc / hosts为我解决了这个问题

@davidino Thx Bro，非常好！ 我有兴趣为什么我们需要这种解决方法？

大家好！ 这里同样的问题。 在巴西，在办公室使用wifi需要很长时间才能启动。 更改/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 。 当我添加两个主机名时，它对我才有用。 因此，如果需要，您仍然可以使用本地DNS ...

对于我来说，这是在稳定版和Beta版上发生的，断开互联网连接或添加主机条目都会为我解决此问题。

埃尔卡皮坦10.11.4
Docker版本1.12.0，内部版本8eab29e，实验性
docker-compose版本1.8.0，内部版本f3628c7
docker-machine版本0.8.0，内部版本b85aac1

我在构建命令上尝试了主机名并断开了Internet连接，但没有任何帮助...尝试了DNS更改...它只在那儿坐了5-10分钟，然后开始了构建过程...我可以看到CPU利用率高了在docker-compose过程中高达100％

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

好沮丧

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

顺便说一句，安装程序可以在工具箱中正常运行，并且运行速度非常快...

进行了详细的调试，我可以看到它挂在这里

[home / docker]-$ docker-compose --verbose build app

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 2016年5月3日
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：找不到身份验证配置

然后又挂了...

我的互联网速度很好，刚刚以60mb / s的速度进行了测试

从代理设置启用Exclude simple hostnames对我来说效果很好。

NO_PROXY=* docker-compose up

解决方法由@jewilmeer发布
https://github.com/docker/compose/issues/3419#issuecomment -221793401为我工作。

在Mac上的Docker README.md或教程中的某个地方通过@jibingeo进行提示会很好。

大家好，@ 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上。

仅仅是我还是对localunixsocket进行DNS查找似乎违反直觉？ 这似乎是一个填充主机名，仅在某些地方需要TCP样式地址而不是本地域套接字时才用作占位符。

无论如何，本地DNS与Google DNS之间的时间差异很有趣...我很好奇是什么原因导致了它。 （遗憾的是，我认为您必须在路由器指向的DNS服务器上再进行一次TCP转储才能知道，除非DNS查找有等效的tracert可以保留递归命中的中间服务器查询）

这也可能会提供信息（在Mac OS X上的man nslookup可以找到）：

Mac OS X通知

nslookup命令不使用主机名和地址解析
或其他正在运行的进程使用的DNS查询路由机制
Mac OSX。由nslookup打印的名称或地址查询的结果
可能与使用Mac OS X的其他进程发现的有所不同
本地名称和地址解析机制。 DNS的结果
查询也可能与使用Mac OS X DNS路由的查询不同
图书馆。

由于他们并没有真正说明nslookup _does_使用什么特定机制与Mac OS X提供的机制有关，因此很难说是否可以期望Docker共享nslookup的行为，或其他Mac OS X应用程序...（我猜是它使用nslookup使用的相同方法，但我们可能必须深入研究代码才能明确地找出两者）

嘿@whitelynx

这是使用本地DNS和Google DNS进行的TCP转储。 我以前进行转储的命令是

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)

在这里，我可以看到本地DNS延迟约3秒。

注意：我在这里使用的路由器与我在previos评论中使用的路由器不同

大家好，
在Mac升级到docker Version 1.12.1 (build: 12133)我不得不添加
127.0.0.1 localunixsocket再次在/etc/hosts

我也必须做大卫做的事。

解决这个非常烦人的错误没有估计？

我只需要添加127.0.0.1 localunixsocket.lan即可使其工作。 我正在使用macOS Sierra。

我真的不知道这是否是相同的问题，但是@jibingeo的回复帮助了我。
在我的公司环境中，使用Docker Toolbox for Windows的_docker-compose_也非常慢。 配置NO_PROXY=*对我有帮助，但这会干扰我的公司代理。 所以我尝试了一下，发现了一个更具体的解决方案（假设您使用的是默认docker VirtualBox ip范围192.168.99.0/24）：

NO_PROXY=192.168.99.0/24可以加速所有操作，因此compose无需尝试使用我的公司内部IP代理。

有关？ https://github.com/SeleniumHQ/docker-selenium/issues/227

将127.0.0.1 localunixsocket放入您的/etc/hosts @davidino解决方案为我解决了这个问题。

现在快得多了

我遇到了同样的问题。 我尝试关闭wifi，将多个条目添加到主机文件中未成功。 我在Linux机器上尝试了相同的设置，结果更快。

构建似乎以不错的速度运行，但是一旦我对正在运行的容器发出任何请求，结果将是可怕的。 无论是简单的文本响应，任何请求都需要30秒左右的时间。

我正在运行带有Rails堆栈的Mac OS Sierra（10.12.1）和Docker for Mac（1.12.1）。

我正在使用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

我在Beta通道docker 1.12.3-beta29.2（13499）

@gardner我已将其添加到主机文件中，但尝试了Beta版却没有成功。 我真的开始认为这与Sierra有关。 我很确定升级之前它能正常工作。 我将再次尝试该Beta，以查看它是否有效。 我会在测试后再次发布。

@gardner同样的问题。 现在运行Docker 1.12.3-beta29.3（13640）。 我的linux设置仍以1/4的RAM更快地运行。

我能说的最好的是，这是Docker与主机之间的IO问题。 我在请求上运行了火焰图，并且大部分时间都在读取文件上。
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-mount-volumes-extremely-slow-cpu-bound/8076/223

同样也遇到了这个问题，对主机的更改虽然有所不同，但仍然有些迟钝。
127.0.0.1 localunixsocket.local 127.0.0.1 localunixsocket

我在运行以下OSX 10.11.6和以下Docker版本的以下稳定Docker版本上看到了这一点：

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

我在慢速的云连接（伦敦一家咖啡馆的云）上看到了这一点，当我关闭WiFi时，撰写速度非常快，否则一切运行都很缓慢...

对于经历此问题的人们，最新版本（1.9.0）似乎没有任何改变吗？

@ shin-我的docker-compose --version仍然有1.8.1 ，最新的Docker for Mac。 我们什么时候可以期待更新？

我们什么时候可以期望解决此问题？

1.9处于beta通道中，不确定何时会稳定发布
在一个星期左右。

在2016年11月18日上午8:07，“ David Richards” [email protected]写道：

@ shin- https://github.com/shin-我的docker-compose仍然有1.8.1
--version与最新的Mac版Docker。 我们什么时候可以期待更新？

-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看
https://github.com/docker/compose/issues/3419#issuecomment-261472095 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AAdcPBV7gMv0kMwil0SEz3etChNY6ej3ks5q_VyugaJpZM4IXnGd
。

对我而言， McAfee Endpoint Security是docker-compose非常慢的原因。 似乎按访问扫描程序确实在破坏每次执行docker-compose时都会发生的解压缩python环境的性能。

对我而言，删除.local搜索域会有所不同。

@ shin-在1.9.0-rc4我仍然遇到问题。 我不知道自己做了什么，但是几天前我没有遇到问题，使用docker-compose超过一年。
docker-compose --version真的很快
docker-compose ps非常慢
禁用Wifi- ps也很快

@gsong不幸的是这对我没有帮助

我也突然开始遇到这个问题。 就像@timsuchanek一样，我已经使用docker-compose up几乎无限期地挂起。 像其他所有人一样，当我关闭wifi时，它可以工作。

我在docker-compose version 1.9.0, build 2585387

编辑：将127.0.0.1 localunixsocket到/etc/hosts现在已将其修复。 我在macOS 10.11.6上

优胜美地引入的.local变化有什么机会？

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

我看到@afxjzs之前提到过它，但是没有任何后续行动。

在尝试使xdebug正常工作时，我偶然发现了一些对我有用的东西：

sudo ifconfig en0 alias 10.254.254.254 255.255.255.0

在主机上。

感谢James Cowie 。

编辑：看起来xdebug是我的问题的根源。 关闭xdebug后，即使/ etc / hosts处于默认状态，我的docker机器也超快。 打开它，并将我的xdebug.remote_host设置为10.254.254.254，它会减慢爬网速度。 建议对/ etc / hosts进行的编辑无济于事，但是如上所述在en0上设置localhost别名可以解决此问题。

最新的稳定版Mac版Docker（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

我注意到，任何无响应的搜索域都会使docker-compose非常慢。 我使用的不仅仅是.local .dev 。

我今天遇到了同样的问题，即使是显示帮助或--version，docker-compose也要永久挂起。 我遵循@jewilmeer有关使用tcpdump的建议，在我的情况下，通过在/ etc主机中添加127.0.0.1 prod.python.map.fastly.net解决了问题

我觉得很奇怪吗？

这里同样的问题。 看起来好像挂了两次，每次挂25秒左右。 这是插入了每个HANG的--verbose输出

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，它将解决速度问题。

最新的Docker版本（Docker版本17.03.1-ce-rc1，内部版本3476dbf）。 我尝试了Beta版和稳定版。

在我的情况下， docker --version需要32秒来输出版本。

这个问题已经存在了将近一年了。

@mobileka您在谈论docker或docker-compose吗？

@ shin-就我而言，与docker相关的每个cli命令（无论是docker还是docker-compose ）在实际给出结果之前或开始执行其工作之前，都有30秒左右的延迟。

@mobileka好的-绝对与此处描述的问题无关。 考虑改为在Docker for Mac存储库上创建问题。

@ shin-抱歉，我没有意识到我输入了错误的回购信息，因为“症状”非常相似：互联网连接处于活动状态时速度很慢，而没有互联网连接时速度很快。

谢谢，我将在Docker for Mac存储库中创建一个问题。

如果这能碰到其他任何人，我很确定我与Consul的玩耍（以及随后的工作搞砸了）在/ etc / resolvers中添加了一个配置文件。 这导致了类似于@seeekr的问题，该错误是由于看到localunixsocket，就像这样：

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变量，排除简单主机名或将DNS更改为8.8.8.8都不对）。

我写了一个玩具网站（逻辑非常简单，应该没有性能问题），并使用docker-compose在本地运行。 事实证明，几乎每个页面都需要几分钟才能加载。 有指示吗？

您的应用程序的@mqliang页面加载时间似乎与此问题完全无关，通常与Compose也无关。

MacOS Sierra，10.12.5。
Docker社区版
版本17.06.0-ce-mac18（18433）
频道：稳定
d9b66511e0

我已经有DNS 8.8.8.8。 需要将localunixsocket.local和localunixsocket添加到/ etc / hosts中。 将它添加到我正在运行的docker-compose的那一刻起，就栩栩如生了。

我不确定这是否对任何人都有用-但我已经安装了dnscrypt，并且切换到docker beta之后，docker compose的运行速度非常慢。 重新安装dnscrypt（通过brew cask）为我解决了这个问题。

我爱你@jewilmeer

只是想离开这里。 我的问题是我的构建上下文中的会话文件。 这些文件归apache用户所有，而docker-compose构建将在此行之后挂起：

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

最可悲的是，我很久以前就停止使用基于文件的会话。 应该不时清理我的工作区。

发表评论的原因：如果compose不只是挂起，那就太好了。 我只是直接使用docker build找出了罪魁祸首，这很好地告诉了我我的问题。

@paali您可以详细说明您的确切做法吗？

@ Vad1mo我的完整设置非常复杂（而且杂乱且正在进行中），但基本部分是Symfony2项目。 在./app/sessions文件夹中有Apache用户拥有的旧会话文件（在docker时间之前）。

基本上我有
COPY app app/
在Dockerfile和docker-compose.yml中构建特定的Dockerfile。
使用的命令：
docker-compose -f docker-compose-ci.yml build --no-cache --force-rm

如前所述，构建过程从未真正开始过，而是在有关auth标头的行中冻结了。 在docker上进行构建直接给了我：

> 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的Docker上。

除了必须告诉每个人添加主机规则或关闭代理之外，还有什么真正的解决方案？

+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。 我重新安装了docker，无法重现该问题。

今天，在Mac上的第一天，我遇到了这个问题。
在将行插入/etc/hosts之后，Docker compose刚刚停顿了，它开始按预期运行。
我使用的是WiFi ，办公室中每个使用相同版本的以太网的人都从未听说过此问题。
码头工人： 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

我在/etc/hosts添加了127.0.0.1 localunixsocket ，对我有用，谢谢！
（但它仍然是wtf的错误）

在最新版本上仍然存在问题。 上面的修复程序似乎对我没有任何帮助，有时它变得太慢以至于挂起。 对我来说，解决方法是每隔一次重新启动Docker for mac。

确认/etc/hosts中的127.0.0.1 localunixsocket /etc/hosts大大加快速度，请解决！

在/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版）。

实际上，我对于为什么会一开始就感到好奇。 对于我来说，必须修改主机文件作为解决最近引入的问题并将其声明为“解决方案”的变通办法，这对我来说似乎有点愚蠢。

这是导致虚假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的更改是主机还是docker容器？

要修改哪个主机文件？

1. macOS主机文件？
2. Linux VM充当Docker主机？
3. 容器本身？

不知道为什么，但是我必须删除任何本地域元素才能使其工作。

/ etc / hosts：
127.0.0.1 localunixsocket

天才！！！