Compose: 도커-Mac OS 베타 용 도커에서 느리게 작성

핑 @frenchben : 미소 :

+1

같은 문제가 생겼습니다 : D

WiFi를 끄면 @ smith64fx 문제도 사라집니다.

@stijn 예, Wi-Fi를 끄면 모든 것이 매력처럼 작동합니다.

Von Meinem iPhone gesendet

오전 05.05.2016 um 00:26 schrieb Sebastiaan van Stijn [email protected] :

WiFi를 끄면 @ smith64fx 문제도 사라집니다.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하거나 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')

네트워킹이 없으면 attach <-와 attach->로 반환되는 위치 사이에 ~ 100-200 줄의 'compose.parallel.feed_queue : Pending : set ([])'이 표시됩니다.

이 시점 이전에는 네트워크에서도 더 많은 일이 발생하지만 대부분은 이미지 등을 검사하기위한 더 많은 호출이있는 것 같습니다.

봇 상황을 위해 compose --verbose의 출력을 첨부했습니다. compose 파일은 허브에서 바로 나온 두 개의 컨테이너입니다.

with-networking.txt
without-networking.txt

@holstvoogd 오, 공급자에게는 좋습니다. 정보 주셔서 감사합니다. 조금 걱정되었습니다. :)

@Erwyn @ smith64fx 확인하려면 항상 연결되어 있고 (하드 유선) Wi-Fi로 동일한 네트워크를 동시에 사용하십니까?

@FrenchBen 아니요, 집의 Wi-Fi 네트워크에만 있습니다. 제 사무실에서는 매우 빠릅니다. 하지만 문제는 집에있는 모든 것들이 빠르게 실행된다는 것입니다. docker-compose ^ _ ^ "

@FrenchBen @ @holstvoogd 는 유선 연결과 동일한 문제가있는 것 같습니다.

Mac 용 Docker 베타에서 동일한 문제가 발견되었습니다. docker-compose up 는 Wi-Fi가 활성화되면 느리고 Wi-Fi가 비활성화되면 빠릅니다.

• Docker Compose 버전 : docker-compose 버전 1.7.1, 빌드 0a9ab35
• Docker 버전 : Docker 버전 1.11.1, 빌드 5604cbe
• OS 버전 : OS X El Capitan 10.11.4

안녕하세요, 이것에 대한 소식이 있습니까?

나는 같은 문제가 있습니다. Compose / Docker / OSX 버전은 @eugenesia 와 동일합니다.
집과 사무실에서 WiFi를 사용하고 집에서 매우 느리게 작동합니다. 사무실에서는 예상대로 작동합니다 (빠름).

내 ISP의 DNS 서버 (가정 및 사무실 인터넷 제공 업체가 다름)와 관련된 것일 수 있다고 생각하고 Google의 DNS를 포함한 일부 공용 DNS를 사용하려고했지만 도움이되지 않았습니다.

WiFi를 끄면 docker-compose 가 정말 빠르게 작동합니다.

@KryDos 이번 주에는 속도가 약간 개선 된 새 릴리스가 나올 예정입니다.

Mac 1.11.1-beta13 용 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 버전 : OS X El Capitan 10.11.5

나는 같은 문제를 겪었고 docker-compose가 localunixsocket.local 해결하려고한다는 것을 언급하는 게시물 (죄송합니다, 심판을 잃었습니다)을 발견했습니다. sudo tcpdump -A -s0 -nni en0 port 53 실행하여 DNS 조회에 대한 통찰력을 얻을 수 있습니다.

지금은 localunixsocket.local localhost를 /etc/hosts . 이제 모든 것이 다시 빨라졌습니다.

127.0.0.1 localunixsocket.local

감사합니다 @jewilmeer , 유용 해 보입니다.

docker-machine과 함께 virtualbox를 사용하여 다시 전환했습니다. 문제가 없으며 Docker Mac Beta보다 최대 10 배 빠릅니다!

@ smith64fx 의견을 건설적으로 유지하십시오. 베타 버전이며 아직 완제품이 아니므로 버그 및 성능 문제가 예상됩니다. 문제를 해결하기 위해보고 (및 테스트)가 필요한 것은 바로 이러한 종류의 문제입니다.

@jewilmeer 님! 나를 위해 tcpdump 명령을 사용하여 발견 한 / etc / hosts에 주소를 몇 개 더 추가해야했습니다.

# (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 편집에 대한 이전 제안을 시도했습니다. 사무실 네트워크에서 도커는 매우 느립니다. 홈 네트워크에서 또는 휴대폰에 테 더링을 사용하면 모든 속도 저하가 제거되고 모든 것이 빠릅니다.

우리는 4 개의 서비스 컨테이너 (postgres, redis, rabbitmq, elasticsearch)에 연결된 웹 컨테이너와 함께 docker-compose를 사용하고 있습니다. OSX에서 직접 4 개의 서비스 컨테이너에 연결하는 것이 좋습니다. 웹 컨테이너에서 서비스 컨테이너로 연결하려고 할 때만 느립니다.

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)

그리고 이것은 우리 사무실 와이파 이에있을 때의 출력입니다 :

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를 비활성화하면이 속도도 완전히 저하됩니다. 비활성화했다가 다시 활성화해도 도움이되지 않습니다.

물론 질문을 게시 한 직후에 자신 만의 솔루션을 찾을 수 있습니다. 개발 환경에 설치된 패키지가 문제를 일으키는 OSX의 DNS 설정을 업데이트 한 것 같습니다. /etc/resolv.conf의 기본값을 사용하도록 OSX DNS를 재설정하면 모든 것이 작동합니다.

Bonjour '소유' .local 및 IPV6 버그와 관련된 문제 일 수 있습니까?
세부 정보 : https://news.ycombinator.com/item?id=11567442

도움이되지만 이전에이 문제가 발생하여 DNS 서버를 8.8.8.8 및 8.8.4.4 로 변경하여 문제를 해결했습니다.

또한이 문제는 내 홈 네트워크에서만 발생했습니다. 직장에서 나는이 문제가 없었습니다.

@jewilmeer 의 수정을 시도한 후에도 동일한 문제에 직면하고 있습니다.
docker-compose up은 사무실 네트워크에서 잘 작동하지만 홈 네트워크에서는 약 7 분 정도 걸립니다.
stop, pull, ps 등과 같은 다른 docker-compose 명령과 동일한 동작.

도커 버전
Docker 버전 1.12.0-rc2, 빌드 906eacd, 실험용

docker-compose-버전
docker-compose 버전 1.8.0-rc1, 빌드 9bf6bc6

docker-machine-버전
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 등 / 호스트에게 문제가 해결되었습니다.

@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 를 추가해보세요. 두 호스트 이름을 모두 추가했을 때 저에게 효과적이었습니다. 따라서 필요한 경우 로컬 DNS를 계속 사용할 수 있습니다.

이것은 안정 및 베타 채널 모두에서 발생하며 인터넷 연결을 끊거나 호스트 항목을 추가하면 문제가 해결됩니다.

엘 캐피 탄 10.11.4
Docker 버전 1.12.0, 빌드 8eab29e, 실험적
docker-compose 버전 1.8.0, 빌드 f3628c7
docker-machine 버전 0.8.0, 빌드 b85aac1

빌드 명령에서 호스트 이름과 인터넷 연결 해제를 모두 시도했지만 아무것도 도움이되지 않았습니다 ... DNS 변경도 시도했습니다 ... 5-10 분 동안 그대로 둔 다음 빌드 프로세스를 시작합니다 ... CPU 사용률이 이동하는 것을 볼 수 있습니다. 도커 작성 프로세스에서 최대 100 %

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

너무 답답하다

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

btw 설정은 도구 상자에서 잘 작동했고 매우 빠르게 실행되었습니다 ...

자세한 디버깅을 사용하면 여기에 매달려있는 것을 볼 수 있습니다.

[home / docker]-$ docker-compose --verbose 빌드 앱

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, 버전 = 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이 저에게 효과적입니다.

Docker for Mac 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 조회에 대해 tracert 해당하는 항목이 없으면 라우터가 가리키는 DNS 서버에 또 다른 TCP 덤프가 있어야한다고 생각합니다

이 정보도 유용 할 수 있습니다 (Mac OS X의 man nslookup 에 있음).

Mac OS X 알림

nslookup 명령은 호스트 이름 및 주소 확인을 사용하지 않습니다.
또는 다른 프로세스에서 실행되는 DNS 쿼리 라우팅 메커니즘
Mac OS X. nslookup 인쇄 된 이름 또는 주소 쿼리의 결과
Mac OS X를 사용하는 다른 프로세스에서 찾은 것과 다를 수 있습니다.
네이티브 이름 및 주소 확인 메커니즘. DNS의 결과
쿼리는 Mac OS X DNS 라우팅을 사용하는 쿼리와 다를 수도 있습니다.
도서관.

Mac OS X가 제공하는 것과 비교하여 nslookup _ 사용 _하는 특정 메커니즘에 대해 설명하지 않기 때문에 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 초 지연을 볼 수 있습니다.

참고 : 여기서 사용한 라우터는 이전 댓글에 사용한 라우터와 다릅니다

안녕하세요,
Mac 용 Docker로 업그레이드 한 후 Version 1.12.1 (build: 12133)
127.0.0.1 localunixsocket 다시 /etc/hosts

Davidino도했던 일을해야했습니다.

이 매우 성가신 버그를 해결하는 데 대한 평가가 없습니까?

작동하려면 127.0.0.1 localunixsocket.lan 도 추가해야했습니다. macOS Sierra를 사용하고 있습니다.

이것이 같은 문제인지는 잘 모르겠지만 @jibingeo 의 답변이 도움이되었습니다.
_docker-compose_는 Windows 용 Docker Toolbox를 사용하는 회사 환경에서도 매우 느립니다. NO_PROXY=* 하는 것도 도움이되었지만 회사 프록시를 방해합니다. 그래서 나는 조금 시도했고 더 구체적인 해결책을 찾았습니다 (기본 도커 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 솔루션이 문제를 해결했습니다.

이제 훨씬 더 빠르게

나는 같은 문제가 있습니다. Wi-Fi를 끄고 호스트 파일에 여러 항목을 추가하여 성공하지 못했습니다. 내 리눅스 상자에서 동일한 설정을 시도했으며 결과가 훨씬 빠릅니다.

빌드가 적당한 속도로 실행되는 것 같지만 실행중인 컨테이너에 요청을하면 결과가 끔찍합니다. 간단한 텍스트 응답이라도 모든 요청에 ​​대해 약 30 초.

Rails 스택과 함께 Mac OS Sierra (10.12.1) 및 Mac 용 Docker (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

베타 채널 도커 1.12.3-beta29.2 (13499)를 사용 중입니다.

@gardner 나는 그것을 호스트 파일에 추가했으며 베타를 성공하지 못했습니다. 나는 그것이 Sierra와 관련이 있다고 생각하기 시작했다. 업그레이드하기 전에 제대로 작동하고 있다고 확신합니다. 베타가 작동하는지 확인하기 위해 또 다른 시도를 할 것입니다. 테스트 후 다시 게시하겠습니다.

@gardner 같은 문제입니다. 이제 Docker 1.12.3-beta29.3 (13640)을 실행합니다. 내 리눅스 설정은 여전히 ​​램의 1/4로 더 빠르게 실행되고 있습니다.

내가 말할 수있는 가장 좋은 점은 도커와 호스트 컴퓨터 간의 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-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

느린 클라우드 연결 (런던의 카페에있는 클라우드)에서이 현상을보고 있습니다. WiFi를 끄면 작성이 매우 빠릅니다. 그렇지 않으면 모든 것이 매우 느리게 실행됩니다.

최신 릴리스 (1.9.0)가 문제를 겪고있는 사람들에게 변경된 것 같습니까?

@ shin- 최신 Mac 용 Docker를 사용하면 docker-compose --version 1.8.1 이 있습니다. 언제 업데이트를 기대할 수 있습니까?

이 문제에 대한 해결책을 언제 기대할 수 있습니까?

1.9는 베타 채널에 있으며 언제 안정적으로 출시 될지 확실하지 않습니다.
일주일 정도.

2016 년 11 월 18 일 오전 8시 7 분에 "David Richards" [email protected]이 작성했습니다.

@ shin- https://github.com/shin- 여전히 내 docker-compose에 1.8.1이 있습니다.
--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가 실행될 때마다 발생하는 것처럼 보이는 파이썬 환경의 압축 풀기 성능을 실제로 죽이는 것처럼 보입니다.

나를 위해 .local 검색 도메인을 제거하면 모든 차이가 생겼습니다.

@ shin-에서 1.9.0-rc4 여전히 문제가 있습니다. 내가 무엇을했는지 모르겠지만 며칠 전에는 docker-compose 를
docker-compose --version 은 정말 빠릅니다
docker-compose ps 매우 느림
Wi-Fi 사용 중지- ps 도 빠릅니다.

@gsong 안타깝게도 저에게 도움이되지 않았습니다.

나는 또한 갑자기이 문제가 발생하기 시작했습니다. @timsuchanek 처럼 저는 약 1 년 동안 docker-compose를 사용해 왔으며 docker-compose up 거의 무기한 중단됩니다. 다른 사람들과 마찬가지로 Wi-Fi를 끄면 작동합니다.

나는 docker-compose version 1.9.0, build 2585387

편집 : 추가 127.0.0.1 localunixsocket 에 /etc/hosts 지금 그것을 고정. 나는 macOS 10.11.6에 있습니다.

요세미티에 도입 된 .local 변경으로 인한 가능성은 얼마나됩니까?

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

호스트 컴퓨터에서.

James Cowie 에게 감사드립니다.

편집 : xdebug가 내 문제의 근원 인 것 같습니다. xdebug를 끄면 / etc / hosts가 기본 상태 인 경우에도 내 도커 머신은 매우 빠릅니다. 그것을 켜고 내 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이 내 문제를 해결했습니다.

나는 같은 오류가 있습니다. /etc/hosts localunixsocket 추가. 작동하지 않았다. 프록시 탭에서 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 .

오늘 도커 작성과 함께 동일한 문제가 발생하여 도움말 또는 --version을 표시하기 위해 영원히 매달려 있습니다. 나는 tcpdump 사용에 대한 @jewilmeer의 조언을 따랐고 내 경우에는 / 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). 베타 버전과 안정적인 버전을 모두 시도했습니다.

docker --version 내 경우 버전을 출력하는 데 32 초가 걸립니다.

이 문제는 거의 1 년 동안 발생했습니다 ...

@mobileka docker 또는 docker-compose 대해 말씀하시는 건가요?

@ shin- 내 경우에는 docker와 관련된 모든 단일 cli 명령 ( docker 또는 docker-compose )이 실제로 결과를 제공하거나 작업을 시작하기 전에 30 초 정도의 지연 시간이 있습니다.

@mobileka 좋아요-여기에 설명 된 문제와는 확실히 관련이 없습니다. 대신 Mac 용 Docker 리포지토리 에서 문제를 생성하는 것이 좋습니다.

@ shin- 죄송합니다. "증상"이 매우 유사했기 때문에 제가 잘못된 저장소에 있다는 사실을 몰랐습니다. 인터넷 연결이 활성화되면 느리고 인터넷 연결이 없으면 빠릅니다.

감사합니다. Mac 용 Docker 리포지토리에서 문제를 생성하겠습니다.

이것이 다른 사람에게 영향을 미칠 가능성이있는 경우, Consul과 함께 놀고 (그리고 그 이후의 망쳐 놓은) / etc / resolvers에 설정 파일을 추가했다고 확신합니다. 이로 인해 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

이미 8.8.8.8로 DNS가 있습니다. localunixsocket.local 및 localunixsocket을 모두 / etc / hosts에 추가해야합니다. 이것이 내 실행중인 docker-compose가 추가 된 순간에 생명을 불어 넣었습니다.

이것이 누구에게도 도움이되는지 확실하지 않지만 dnscrypt를 설치했으며 docker beta로 전환 한 후 docker compose가 엄청나게 느 렸습니다. (brew cask를 통해) dnscrypt를 다시 설치하면 문제가 해결되었습니다.

사랑 해요 @jewilmeer

그냥 여기에두고 싶었어요. 내 문제는 내 빌드 컨텍스트 내의 세션 파일이었습니다. 파일은 아파치 사용자가 소유했으며 docker-compose 빌드는 다음 줄 다음에 중단됩니다.

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

가장 안타까운 것은 오래 전에 파일 기반 세션 사용을 중단했다는 것입니다. 가끔 내 작업 공간을 청소해야합니다.

댓글을 달아야하는 이유 : compose가 그냥 멈추지 않는다면 정말 좋을 것입니다. 나는 내 문제에 대해 잘 알려주는 도커 빌드를 직접 사용하여 범인을 찾았습니다.

@paali 정확히 무엇을했는지 자세히

@ Vad1mo 내 전체 설정은 매우 복잡하고 (지저분하고 진행 중) 기본 부분은 Symfony2 프로젝트입니다. apache 사용자가 소유 한 ./app/sessions 폴더에 이전 세션 파일이 있습니다 (도커 시간 이전).

기본적으로 나는
COPY app app/
Dockerfiles 및 docker-compose.yml에서 개별 Dockerfile을 빌드합니다.
사용 된 명령 :
docker-compose -f docker-compose-ci.yml build --no-cache --force-rm

언급했듯이 빌드 프로세스는 실제로 시작되지 않았지만 인증 헤더에 대한 줄 후에 정지되었습니다. 도커에서 직접 빌드하면 다음과 같은 이점이 있습니다.

> 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에서 처음으로이 문제를 다루었습니다.
Docker compose는 문자 그대로 /etc/hosts 줄을 삽입 한 후 예상대로 작동하기 시작했습니다.
나는 WiFi 를 사용하고 있었는데, 사무실의 모든 사람들이 이더넷에서 동일한 버전을 사용하여이 문제를 들어 본 적이 없습니다.
Docker : Version 17.09.0-ce-mac35 (19611)
맥 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 버그입니다)

최신 버전에 여전히 문제가 있습니다. 위의 수정 사항은 나를 위해 아무것도하지 않는 것 같습니다. 어떤 시점에서는 너무 느려져서 중단됩니다. 나를위한 해결 방법은 Mac 용 Docker를 자주 다시 시작하는 것입니다.

/etc/hosts 127.0.0.1 localunixsocket 가) 작업 속도를 크게 높이는 것을 확인했습니다. 수정하십시오!

추가 127.0.0.1 localunixsocket 에 /etc/hosts 도움이됩니다. docker-compose version 1.18.0, build 8dd22a9

@norbertsienkiewicz가 권장하는 솔루션은 저에게 완벽하게 작동했습니다. 내 docker-compose up 시간이 10 분 이상에서 1 분 미만 (버전 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에 대한 변경 사항이 호스트 시스템 또는 도커 컨테이너입니까 ??

수정할 호스트 파일은 무엇입니까?

1. macOS 호스트 파일?
2. Docker 호스트 역할을하는 Linux VM?
3. 컨테이너 자체?

이유는 확실하지 않지만 작동하도록 로컬 도메인 요소를 제거해야했습니다.

/ etc / hosts :
127.0.0.1 localunixsocket

천재!!!