Compose: buruh pelabuhan-menulis lambat di buruh pelabuhan untuk mac os beta

ping @frenchben : smile:

+1

mendapat masalah yang sama: D

Masalah @ smith64fx juga hilang jika Anda mematikan WiFi?

@stijn Ya, ketika saya mematikan wifi semuanya bekerja seperti pesona

Von meinem iPhone gesendet

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

Masalah @ smith64fx juga hilang jika Anda mematikan WiFi?

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub

@ smith64fx Saya melihat dari tanda tangan Anda bahwa Anda kemungkinan besar dari Jerman (atau Austria / swiss). Apakah Anda keberatan saya bertanya apa penyedia Internet Anda? Saya bertanya-tanya apakah kita memiliki yang sama, dan apakah itu bisa berasal dari kotak yang tidak terlihat seperti perangkat keras / perangkat lunak yang sangat bagus dan tidak akan bertindak seperti yang dipikirkan oleh buruh pelabuhan.

(Saya dengan Vodafone dan saya memiliki kotak mudah mereka-apa pun)

Masalah yang sama pada jaringan kabel (jaringan perusahaan), segera setelah saya mencabut semuanya sangat cepat. Jadi saya yakin itu tidak terkait dengan penyedia khusus Anda.

Saya telah melihat output verbose, tidak ada kesalahan yang jelas (atau di mana pun di log sistem). Apakah perhatikan ini:

Tanpa jaringan, baris ini dikelompokkan bersama:

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

Tanpa jaringan, saya mendapatkan ~ 100-200 baris 'compose.parallel.feed_queue: Pending: set ([])' antara lampirkan <- dan di mana ia kembali dengan lampirkan -> ...

Sebelum titik ini, ada lebih banyak hal yang terjadi dengan jaringan juga, tetapi kebanyakan hanya lebih banyak panggilan untuk memeriksa gambar, dll.

Saya telah melampirkan output dari compose --verbose up untuk situasi bot. File compose hanya dua kontainer langsung dari hub.

dengan-jaringan.txt
tanpa-jaringan.txt

@holstvoogd oh, ok untuk penyedia. Terima kasih atas infonya, saya agak khawatir :)

@Erwyn @ smith64fx Untuk mengonfirmasi, Anda selalu terhubung (terprogram) dan pada saat yang sama menggunakan jaringan yang sama dengan wifi?

@FrenchBen Tidak, itu hanya di jaringan wifi di rumah saya. Di kantor saya sangat cepat. Tapi masalahnya, semua hal lain di rumah berjalan cepat, kecuali docker-compose ^ _ ^ "

@Prancis sama dengan @ smpn. Ini hanya wifi di rumah jadi tidak ada koneksi kabel yang terlibat. Dan seperti yang saya lihat, @holstvoogd tampaknya memiliki masalah yang sama dengan koneksi kabel.

Saya memperhatikan masalah yang sama dengan Docker untuk Mac Beta. docker-compose up lambat saat Wifi diaktifkan, cepat saat Wifi dinonaktifkan.

• Versi Docker Compose: docker-compose versi 1.7.1, build 0a9ab35
• Versi Docker: Docker versi 1.11.1, build 5604cbe
• Versi OS: OS X El Capitan 10.11.4

Hai apa ada kabar tentang ini?

Saya memiliki masalah yang sama. Versi compose / Docker / OSX sama dengan yang
Saya menggunakan WiFi di rumah dan di kantor dan di rumah saya berfungsi sangat lambat. Di kantor berfungsi seperti yang diharapkan (cepat).

Saya pikir mungkin itu adalah sesuatu yang terkait dengan server DNS dari ISP saya (penyedia internet rumah dan kantor berbeda) dan saya mencoba menggunakan beberapa DNS publik termasuk yang dari Google tetapi tidak membantu.

Jika saya mematikan WiFi maka docker-compose bekerja sangat cepat

@KryDos Sebuah rilis baru akan keluar minggu ini dengan beberapa peningkatan kecepatan

Saya memiliki masalah yang sama, setelah memperbarui ke buruh pelabuhan untuk mac 1.11.1-beta13, masalah tetap ada. Solusi dengan mematikan dan menghidupkan kembali jaringan tidak berfungsi lagi, layanan mulai cepat ketika mematikan jaringan, tetapi ketika menghidupkan kembali jaringan, layanan tidak lagi dapat diakses dan daemon buruh pelabuhan tidak merespons

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

• Versi Docker Compose: docker-compose versi 1.7.1, build 0a9ab35
• Versi Docker: Docker versi 1.11.1-beta13, build 7975
• Versi OS: OS X El Capitan 10.11.5

Saya mengalami masalah yang sama, dan menemukan sebuah kiriman (maaf, kehilangan referensi) yang menyebutkan docker-compose sedang mencoba menyelesaikan localunixsocket.local . Anda bisa mendapatkan wawasan tentang pencarian dns dengan menjalankan sudo tcpdump -A -s0 -nni en0 port 53

Untuk saat ini saya telah mengarahkan localunixsocket.local ke localhost di /etc/hosts . Sekarang semuanya cepat lagi.

127.0.0.1 localunixsocket.local

Terima kasih @jewilmeer , itu terlihat berguna

Saya beralih kembali menggunakan virtualbox dengan mesin buruh pelabuhan. Masalah tidak ada dan hingga 10x lebih cepat dari Docker Mac Beta!

@ smpn1sjd harap jaga komentar anda agar tetap konstruktif; Ini adalah beta, ini belum menjadi produk jadi, jadi bug dan masalah kinerja diharapkan. Persis seperti inilah yang membutuhkan pelaporan (dan pengujian) untuk menyelesaikannya.

komentar super luar biasa, @jewilmeer! Bagi saya, saya harus menambahkan beberapa alamat lagi ke / etc / hosts yang saya temukan menggunakan perintah 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

Setelah penambahan itu - cepat! Sebenarnya, sangat cepat, tampaknya lebih cepat daripada saat menggunakan Docker Toolbox! woop woop :) (Meskipun itu mungkin pengamatan yang sangat subjektif!)

Itu cukup aneh, tetapi tampaknya menunjukkan apa masalah yang mendasarinya ...

Saat ini saya menghadapi masalah yang sama dan saya tidak dapat menyelesaikan masalah tersebut.
Saya sudah mencoba saran sebelumnya untuk mengedit /etc/hosts . Di jaringan kantor kami, buruh pelabuhan sangat lambat. Di jaringan rumah atau menggunakan tethering ke ponsel menghilangkan semua perlambatan dan semuanya cepat.

Kami menggunakan docker-compose dengan wadah web yang ditautkan ke empat wadah layanan (postgres, redis, rabbitmq, elasticsearch). Menghubungkan ke salah satu dari empat wadah layanan langsung dari OSX tidak masalah. Ini hanya lambat ketika mencoba untuk terhubung dari penampung web ke salah satu penampung layanan.

Menjalankan tcpdump -vvv -s 0 -l -n port 53 memberikan output berikut saat ditambatkan ke ponsel

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)

dan ini adalah keluaran saat di wifi kantor kami:

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)

Jadi sepertinya ada sesuatu dengan pencarian DNS terbalik tetapi saya tidak yakin bagaimana cara memecahkan masalah. Menonaktifkan wifi sepenuhnya menjamin kelambatan ini juga. Menonaktifkan dan mengaktifkan kembali tidak membantu.

Tentu saja Anda menemukan solusi Anda sendiri setelah Anda memposting pertanyaan. Sepertinya paket yang diinstal di lingkungan dev kami memperbarui pengaturan DNS di OSX yang menyebabkan masalah. Setelah saya mereset DNS OSX untuk menggunakan default di /etc/resolv.conf, semuanya bekerja.

Mungkinkah ini terkait dengan masalah dengan Bonjour 'memiliki' .local dan bug IPV6?
detailnya: https://news.ycombinator.com/item?id=11567442

Entah apakah ini membantu tetapi saya dulu mengalami masalah ini dan saya memperbaikinya dengan mengubah server DNS saya menjadi 8.8.8.8 dan 8.8.4.4 .

Juga masalah ini hanya terjadi di jaringan Rumah saya. Di tempat kerja saya tidak mengalami masalah ini.

Saya juga menghadapi masalah yang sama bahkan setelah mencoba memperbaiki @jewilmeer .
buruh pelabuhan-menulis bekerja dengan baik di jaringan kantor saya tetapi membutuhkan sekitar ~ 7 menit di jaringan rumah saya.
perilaku yang sama dengan perintah docker-compose lainnya seperti stop, pull, ps dll.

buruh pelabuhan --version
Docker versi 1.12.0-rc2, build 906eacd, eksperimental

buruh pelabuhan-menulis --version
docker-compose versi 1.8.0-rc1, build 9bf6bc6

buruh pelabuhan - versi
docker-machine versi 0.8.0-rc1, build fffa6c9

Tidak yakin mengapa tetapi saya harus menghapus elemen domain lokal apa pun untuk membuatnya berfungsi.

/ etc / hosts:
127.0.0.1 localunixsocket

Saya memiliki masalah yang sangat mirip, tetapi menurut saya ini mungkin terkait dengan penggunaan DNSCrypt saya ?

@Erwyn Saya pernah mengalami masalah yang sama dengan Vodafone Easybox juga ...
ternyata Vodafone Easybox mengikat pencarian domain .local ke router (untuk mengevaluasi nama host dinamis dari router Anda, yaitu easy.box )
dan tebakan saya adalah bahwa pengikatan ini menyebabkan docker-compose menunggu respons dari router (saya mungkin sepenuhnya salah dalam hal ini) ...
tapi menambahkan
127.0.0.1 localunixsocket.local menjadi etc/hosts memecahkan masalah untuk saya

Hai kawan,
127.0.0.1 localunixsocket ke etc / hosts memecahkan masalah saya

@davidino Thx Bro, bekerja dengan sempurna! Saya tertarik mengapa kita membutuhkan solusi ini?

Hallo teman-teman! Masalah yang sama disini. Di Brazil, menggunakan wifi di kantor butuh waktu lama untuk memulai. Setelah mengubah file /etc/hosts , semuanya bekerja dengan baik.

Masalah yang sama di sini. Bekerja di luar satu kantor (dengan WIFI) saya tidak mengalami masalah atau penundaan. Bekerja di kantor yang berbeda (juga dengan WIFI) saya akan mendapatkan penundaan ~ 10 menit.

Menambahkan 127.0.0.1 localunixsocket ke /etc/hosts tidak _not_ menyelesaikan masalah untuk saya. Saya mencoba melakukan itu dalam kombinasi dengan reboot, tetapi masih tidak berhasil.

Menambahkan 8.8.8.8 dan 8.8.4.4 karena server DNS menyelesaikan masalah.

Terima kasih @Typositoire!

Hai, @dadarek , coba tambahkan 127.0.0.1 localunixsocket.home <hostname>.home di file host Anda. Itu hanya berhasil untuk saya ketika saya menambahkan kedua nama host. Jadi Anda masih dapat menggunakan DNS lokal Anda, jika Anda membutuhkan ...

Ini terjadi pada saya pada saluran stabil dan beta, memutuskan koneksi internet atau menambahkan entri host memperbaikinya untuk saya.

El Capitan 10.11.4
Docker versi 1.12.0, build 8eab29e, eksperimental
docker-compose versi 1.8.0, build f3628c7
docker-machine versi 0.8.0, build b85aac1

Saya mencoba nama host dan memutuskan koneksi internet pada perintah build dan tidak ada yang membantu ... mencoba perubahan DNS juga ... itu hanya duduk di sana selama 5-10 menit dan kemudian memulai proses pembuatan ... Saya dapat melihat penggunaan CPU berjalan hingga 100% pada proses penulisan buruh pelabuhan

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

sangat membuat frustasi

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

btw penyiapan bekerja dengan baik dengan kotak alat dan berjalan sangat cepat ...

dengan debugging verbose di saya bisa melihatnya tergantung di sini

[home / docker] - $ docker-compose - aplikasi buildverbose

compose.config.config.find: Menggunakan file konfigurasi: ./docker-compose.yml
docker.auth.auth.load_config: File tidak ada
compose.cli.command.get_client: docker-compose versi 1.8.0, build f3628c7
versi docker-py: 1.9.0
Versi CPython: 2.7.9
Versi OpenSSL: OpenSSL 1.0.2h 3 Mei 2016
compose.cli.command.get_client: Docker base_url: http + docker: // localunixsocket
compose.cli.command.get_client: Versi Docker: KernelVersion = 4.4.15-moby, Os = linux, BuildTime = 2016-07-28T21: 15: 28.963402499 + 00: 00, ApiVersion = 1.24, Versi = 1.12.0, GitCommit = 8eab29e, Arch = amd64, GoVersion = go1.6.3
compose.service.build: Membangun aplikasi
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 ')

setelah beberapa menit, itu masuk ke

docker.api.build._set_auth_headers: Mencari konfigurasi auth
docker.api.build._set_auth_headers: Tidak ada konfigurasi auth di memori - memuat dari sistem file
docker.auth.auth.load_config: File tidak ada
docker.api.build._set_auth_headers: Tidak ditemukan konfigurasi auth

lalu hang lagi ...

kecepatan internet saya baik-baik saja, hanya diuji pada 60mb / s

mengaktifkan Exclude simple hostnames dari pengaturan proxy bekerja dengan sempurna untuk saya.

NO_PROXY=* docker-compose up

Solusi yang diposting oleh @jewilmeer
https://github.com/docker/compose/issues/3419#issuecomment -221793401 bekerja untuk saya.

Akan lebih baik untuk memiliki tip oleh @jibingeo di Docker untuk Mac README.md atau di suatu tempat di tutorial.

Halo semuanya, @thaJeztah.

Setelah melalui kode sumber, saya menemukan bahwa socket.gethostbyname("localunixsocket") membutuhkan lebih dari 30 detik (dalam kasus saya) untuk dieksekusi.

Jadi saya menanyakan DNS lokal dan DNS Google saya

$ 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 lokal berfungsi sempurna dengan nama host 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

Ini berarti masalah sebenarnya adalah dengan DNS router.

Apakah hanya saya, atau apakah melakukan pencarian DNS untuk localunixsocket tampak berlawanan dengan intuisi? Itu tampak seperti nama host pengisi yang baru saja digunakan sebagai placeholder ketika ada sesuatu yang mengharapkan alamat bergaya TCP, bukan soket domain lokal.

Bagaimanapun, perbedaan waktu antara DNS lokal dan DNS Google menarik ... Saya ingin tahu apa yang menyebabkannya melakukan itu. (sayangnya, saya pikir Anda harus memiliki dump TCP lain di server DNS yang ditunjukkan oleh router untuk memberi tahu, kecuali ada tracert setara untuk pencarian DNS yang dapat mempertahankan server perantara yang terkena rekursif pertanyaan)

Ini mungkin informatif juga (ditemukan di man nslookup di Mac OS X):

PEMBERITAHUAN Mac OS X.

Perintah nslookup tidak menggunakan nama host dan resolusi alamat
atau mekanisme perutean kueri DNS yang digunakan oleh proses lain yang berjalan di
Mac OS X. Hasil query nama atau alamat dicetak oleh nslookup
mungkin berbeda dari yang ditemukan oleh proses lain yang menggunakan Mac OS X
mekanisme resolusi nama dan alamat asli. Hasil DNS
kueri mungkin juga berbeda dari kueri yang menggunakan perutean DNS Mac OS X.
Perpustakaan.

Karena mereka tidak benar-benar memberikan klarifikasi apa pun tentang mekanisme spesifik apa yang digunakan nslookup _does_ vs. apa yang disediakan Mac OS X, sulit untuk mengatakan apakah Docker diharapkan membagikan perilaku nslookup , atau aplikasi Mac OS X lainnya ... (perkiraan saya adalah ia menggunakan metode yang sama dengan nslookup , tetapi kita mungkin harus menggali kode untuk keduanya untuk mengetahuinya secara pasti)

Hei @whitely

Berikut adalah dump TCP yang diambil dengan DNS Lokal dan Google DNS. Perintah yang biasa saya ambil adalah

sudo killall -HUP mDNSResponder && docker-compose ps

Dengan DNS Lokal:

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)

Dengan 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)

Di sini saya dapat melihat penundaan ~ 3 detik dengan DNS Lokal.

Catatan: Router yang saya gunakan di sini berbeda dengan yang saya gunakan untuk komentar sebelumnya

Halo semua,
setelah upgrade ke buruh pelabuhan untuk mac Version 1.12.1 (build: 12133) saya harus menambahkan
127.0.0.1 localunixsocket lagi di /etc/hosts

Saya harus melakukan apa yang dilakukan davidino juga.

Tidak ada perkiraan untuk memecahkan bug yang sangat mengganggu ini?

Saya hanya perlu menambahkan 127.0.0.1 localunixsocket.lan agar berhasil. Saya menggunakan macOS Sierra.

Saya tidak terlalu tahu apakah ini masalah yang sama, tetapi balasan @jibingeo membantu saya.
_docker-compose_ juga sangat lambat di lingkungan perusahaan saya menggunakan Docker Toolbox untuk Windows. Mengkonfigurasi NO_PROXY=* membantu saya, tetapi ini mengganggu proxy perusahaan saya. Jadi saya mencoba sedikit dan saya menemukan solusi yang lebih spesifik (dengan asumsi Anda menggunakan kisaran ip VirtualBox docker default 192.168.99.0/24):

NO_PROXY=192.168.99.0/24 mempercepat semuanya, jadi tulis tidak perlu mencoba proxy perusahaan saya untuk IP internal.

Terkait? https://github.com/SeleniumHQ/docker-selenium/issues/227

Solusi @davidino dengan meletakkan 127.0.0.1 localunixsocket di /etc/hosts menyelesaikan masalah saya.

Jauh lebih cepat sekarang

Saya mengalami masalah yang sama. Saya sudah mencoba mematikan wifi saya, menambahkan beberapa entri ke file host saya tidak berhasil. Saya telah mencoba pengaturan yang sama di kotak linux saya dan hasilnya jauh lebih cepat.

Build tersebut tampaknya berjalan dengan kecepatan yang layak tetapi begitu saya membuat permintaan apa pun ke dalam container yang sedang berjalan, hasilnya mengerikan. Sekitar 30 detik untuk permintaan apa pun, tidak peduli apakah itu respons teks sederhana.

Saya menjalankan Mac OS Sierra (10.12.1) dan Docker untuk Mac (1.12.1) dengan tumpukan Rails.

Saya di 10.11.6 (15G31)

Inilah yang ada di file /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

Saya menggunakan buruh pelabuhan saluran beta 1.12.3-beta29.2 (13499)

@gardner Saya telah menambahkannya ke file host saya dan saya telah mencoba versi beta tetapi tidak berhasil. Saya benar-benar mulai berpikir itu ada hubungannya dengan Sierra. Saya cukup yakin itu berfungsi sebelum saya meningkatkan. Saya akan mencoba beta lagi untuk melihat apakah berhasil. Saya akan posting lagi setelah saya tes.

@gner Masalah yang sama. Sekarang menjalankan Docker 1.12.3-beta29.3 (13640). Setup linux saya masih berjalan lebih cepat dengan 1/4 RAM.

Yang terbaik yang bisa saya katakan adalah bahwa ini adalah masalah IO antara buruh pelabuhan dan mesin host. Saya menjalankan flamegraph atas permintaan dan menghabiskan sebagian besar waktu membaca file.
https://www.dropbox.com/s/4702tx7qqpkr4yd/Screenshot%202016-11-02%2014.39.22.png?dl=0

Ini adalah aplikasi yang sama, permintaan yang sama, berjalan secara lokal.
https://www.dropbox.com/s/xxs5jdug7cllpbu/Screenshot%202016-11-02%2014.44.37.png?dl=0

Jika saya mengonfigurasi aplikasi agar berjalan dalam mode produksi, aplikasi itu berjalan secepat di dalam Docker.

Tidak yakin apakah ini sudah diketahui atau tidak, tetapi mudah-mudahan ini membantu orang lain yang datang ke utas ini mencoba mengetahuinya.

Sunting: Sepertinya ini adalah masalah sebenarnya yang saya hadapi. https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/223

Juga mengalami masalah ini, perubahan pada host membuat sedikit perbedaan, tetapi masih agak lamban.
127.0.0.1 localunixsocket.local 127.0.0.1 localunixsocket

Saya melihat ini pada versi buruh pelabuhan stabil berikut yang menjalankan OSX 10.11.6 dengan versi buruh pelabuhan berikut:

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

Saya melihat ini pada koneksi awan yang lambat (Awan di sebuah kafe di London), ketika saya mematikan WiFi, menulis sangat cepat, jika tidak semuanya berjalan sangat lambat ...

Apakah rilis terbaru (1.9.0) tampaknya mengubah sesuatu untuk orang yang mengalami masalah tersebut?

@ shin- Saya masih memiliki 1.8.1 di docker-compose --version dengan Docker terbaru untuk Mac. Kapan kita bisa mengharapkan pembaruan?

Kapan kita bisa mengharapkan penyelesaian untuk masalah ini?

1.9 ada di saluran beta, mungkin tidak yakin kapan akan dikirimkan dengan stabil
dalam seminggu atau lebih.

Pada 18 Nov 2016 08:07, "David Richards" [email protected] menulis:

@ shin- https://github.com/shin- Saya masih memiliki 1.8.1 di docker-compose saya
--versi dengan Docker terbaru untuk Mac. Kapan kita bisa mengharapkan pembaruan?

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/docker/compose/issues/3419#issuecomment-261472095 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AAdcPBV7gMv0kMwil0SEz3etChNY6ej3ks5q_VyugaJpZM4IXnGd
.

Bagi saya Keamanan Endpoint McAfee adalah alasan pembuatan galangan kapal menjadi sangat lambat. Sepertinya pemindai on-access benar-benar mematikan kinerja pembongkaran lingkungan python yang tampaknya terjadi setiap kali docker-compose dijalankan.

Bagi saya, menghapus domain pencarian .local membuat semua perbedaan.

@ shin- di 1.9.0-rc4 Saya masih memiliki masalah. Saya tidak tahu, apa yang saya lakukan, tetapi beberapa hari yang lalu saya tidak memiliki masalah, menggunakan docker-compose selama lebih dari setahun.
docker-compose --version sangat cepat
docker-compose ps sangat lambat
Menonaktifkan Wifi - ps juga cepat

@gsong sayangnya itu tidak membantu saya

Saya juga tiba-tiba mulai mengalami masalah ini. Sama seperti @timsuchanek saya telah menggunakan docker-compose selama sekitar satu tahun sekarang dan docker-compose up hang hampir tanpa batas. Seperti orang lain, ketika saya mematikan wifi itu berfungsi.

Saya di docker-compose version 1.9.0, build 2585387

Edit: Menambahkan 127.0.0.1 localunixsocket ke /etc/hosts memperbaikinya untuk saat ini. Saya menggunakan macOS 10.11.6

Seberapa besar kemungkinan hal ini disebabkan oleh perubahan .local diperkenalkan di yosemite?

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

Saya melihat bahwa @afxjzs menyebutkannya sebelumnya tetapi tidak melihat ada tindak lanjut.

Saya tersandung pada sesuatu yang berhasil untuk saya, ketika mencoba membuat xdebug berfungsi:

sudo ifconfig en0 alias 10.254.254.254 255.255.255.0

di mesin host.

Terima kasih kepada James Cowie .

Sunting: Sepertinya xdebug adalah akar masalah saya. Dengan xdebug dimatikan, mesin buruh pelabuhan saya super cepat, bahkan dengan / etc / hosts dalam keadaan default-nya. Dengan mengaktifkannya, dan xdebug.remote_host saya disetel ke 10.254.254.254, ini melambat menjadi perayapan. Pengeditan yang disarankan untuk / etc / hosts tidak membantu, tetapi mengatur alias localhost pada en0 seperti di atas memperbaiki masalah.

Ini terjadi pada saya dengan Docker stabil terbaru untuk Mac (1.13.1, docker-compose 1.11.1)

Melakukan NO_PROXY=* bekerja.

Ini terjadi pada saya dengan pembaruan terbaru juga (1.13.1, docker-compose 1.11.1). https://github.com/docker/compose/issues/3419#issuecomment -221793401 menyelesaikan masalah saya.

Saya mempunyai kesalahan yang sama. Menambahkan localunixsocket ke /etc/hosts . tidak bekerja. Perbaikan sementara menandai Exclude simple hostnames di tab proxy.

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

Saya telah memperhatikan bahwa setiap domain pencarian non-responsif membuat penulisan buruh pelabuhan sangat lambat. Bukan hanya .local Saya menggunakan .dev .

Saya mengalami masalah yang sama hari ini dengan docker-compose digantung selamanya bahkan untuk menampilkan bantuan atau --versi. Saya mengikuti saran @jewilmeer tentang menggunakan tcpdump dan dalam kasus saya, masalah diselesaikan dengan menambahkan 127.0.0.1 prod.python.map.fastly.net ke / etc hosts

Cukup aneh, menurutku?

Masalah yang sama di sini. Sepertinya hang dua kali, masing-masing selama sekitar 25 detik. Ini adalah output --verbose dengan setiap HANG disela

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>

Saya mencoba solusi / etc / hosts tanpa peningkatan yang nyata.

Masalah yang sama di sini dan tidak ada solusi dari seluruh utas yang membantu saya (baik /etc/hosts maupun NO_PROXY variabel atau Exclude simple hostnames atau mengubah DNS menjadi 8.8.8.8 ).

Satu hal yang perlu diperhatikan: jika saya menjalankan buruh pelabuhan dengan sudo, itu memecahkan masalah kecepatan.

Versi docker terbaru (versi Docker 17.03.1-ce-rc1, build 3476dbf). Saya mencoba rilis beta dan stabil.

docker --version membutuhkan 32 detik untuk menampilkan versi dalam kasus saya.

Masalah ini telah ada selama hampir setahun sekarang ...

@mobileka Apakah Anda berbicara tentang docker atau docker-compose ?

@ shin- Dalam kasus saya, setiap perintah cli (baik itu docker atau docker-compose ) yang terkait dengan buruh pelabuhan memiliki latensi 30 atau lebih detik sebelum benar-benar memberikan hasil atau sebelum mulai melakukan tugasnya.

@mobileka Oke - itu pasti tidak terkait dengan masalah yang dijelaskan di sini. Pertimbangkan untuk membuat masalah di Docker untuk repo

@ shin- Maaf, saya tidak menyadari bahwa saya dalam repo yang salah karena "gejalanya" sangat mirip: lambat saat koneksi internet aktif dan cepat saat tidak ada koneksi internet.

Terima kasih, saya akan membuat masalah di Docker untuk repo Mac.

Jika ini mengenai orang lain, saya cukup yakin bahwa saya bermain-main (dan kemudian mengacaukannya) dengan Consul menambahkan file konfigurasi di / etc / resolvers. Ini menyebabkan masalah yang mirip dengan yang dilaporkan @seeekr dengan melihat localunixsocket., seperti:

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
...

Menghapus file dari / etc / resolvers segera menyelesaikan masalah.

Semoga membantu!

Masalah yang sama di sini dan tidak ada solusi dari seluruh utas yang membantu saya (baik / etc / hosts maupun variabel NO_PROXY atau Kecualikan nama host sederhana atau ubah DNS ke 8.8.8.8).

Saya menulis situs mainan (logikanya sangat sederhana dan seharusnya tidak memiliki masalah kinerja) dan menjalankannya secara lokal menggunakan docker-compose. Ternyata hampir setiap halaman membutuhkan beberapa menit untuk dimuat. Ada instruksi?

Waktu muat halaman

MacOS Sierra, 10.12.5.
Edisi Komunitas Docker
Versi 17.06.0-ce-mac18 (18433)
Saluran: stabil
d9b66511e0

Saya sudah memiliki DNS sebagai 8.8.8.8. Diperlukan untuk menambahkan localunixsocket.local dan localunixsocket ke / etc / hosts. Begitu ini ditambahkan, penulisan buruh pelabuhan saya yang sedang berjalan menjadi hidup.

Saya tidak yakin apakah ini membantu siapa pun - tetapi saya telah menginstal dnscrypt dan setelah beralih ke docker beta, pembuatan docker sangat lambat. Menginstal ulang dnscrypt (melalui brew cask) memperbaiki masalah saya.

Aku sayang kamu @jewilmeer

Hanya ingin meninggalkan ini di sini. Masalah saya adalah file sesi di dalam konteks build saya. File-file tersebut dimiliki oleh pengguna apache dan build docker-compose hanya akan hang setelah baris ini:

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

Hal yang paling menyedihkan adalah saya sudah lama berhenti menggunakan sesi berbasis file. Mungkin harus membersihkan ruang kerja saya sekarang dan nanti.

Alasan berkomentar: Alangkah baiknya jika menulis tidak hanya digantung. Saya hanya menemukan pelakunya menggunakan docker build secara langsung yang memberi tahu saya tentang masalah saya.

@paali bisakah kamu menjelaskan tentang apa yang sebenarnya kamu lakukan?

@ Vad1mo penyiapan lengkap saya cukup rumit (dan berantakan dan sedang dalam proses) tetapi bagian dasarnya adalah proyek Symfony2. Memiliki file sesi lama di folder ./app/sessions yang dimiliki oleh pengguna apache (sebelum waktu docker).

Pada dasarnya saya punya
COPY app app/
di salah satu Dockerfiles dan docker-compose.yml untuk membangun Dockerfile perticular.
Perintah yang digunakan:
docker-compose -f docker-compose-ci.yml build --no-cache --force-rm

Seperti disebutkan, proses build tidak pernah benar-benar dimulai, tetapi berhenti setelah baris tentang header autentikasi. Melakukan build di buruh pelabuhan secara langsung memberi saya:

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

Lain kali saya akan tahu untuk mencoba buruh pelabuhan secara langsung tapi sepertinya tidak ada yang benar-benar mengisyaratkan apa masalah sebenarnya. Saya menggunakan Docker untuk Mac 7.06.1-ce-mac24.

Adakah kata tentang solusi nyata untuk ini selain harus memberi tahu semua orang untuk menambahkan aturan host atau menonaktifkan proxy?

+1

+1

+1

Apa yang memperbaikinya untuk saya adalah membuka System Preferences / Network / Advanced / DNS / Search Domains, dan menghapus entri ".local." yang telah saya taruh di sana. Ini menyebabkan macOS mengisi Domain Pencarian hanya dengan nilai default, "domain lokal". Dan kemudian docker-compose menjadi responsif lagi.

docker itu sendiri responsif sepanjang waktu.

Saya tidak tahu, tetapi saya akan menebak bahwa mungkin docker dengan benar menemukan sumber daya pada sistem menggunakan alamat IP atau nama lokal yang stabil, sementara docker-compose tidak aman mengandalkan localdomain selalu ditentukan sebagai salah satu domain pencarian. Tapi entahlah!

Saya akan menjalankan baris untuk memantau dns yang ada di posting asli tentang perbaikan:

sudo tcpdump -A -s0 -nni en0 port 53

Itu menunjukkan kepada saya bahwa apa yang perlu saya tambahkan ke file host saya adalah:

127.0.0.1 localunixsocket.localdomain

sepertinya ada sesuatu yang berubah dari .local menjadi .localdomain?

Saya telah melakukan penginstalan baru 10.12 Sierra. Saya menginstal ulang buruh pelabuhan dan tidak dapat mereproduksi masalah tersebut.

Saya membahas masalah ini hari ini, hari pertama saya menggunakan Mac.
Docker compose baru saja terhenti, secara harfiah setelah memasukkan baris ke /etc/hosts itu mulai bekerja seperti yang diharapkan.
Saya menggunakan WiFi , semua orang di kantor dengan versi yang sama di Ethernet bahkan tidak pernah mendengar masalah ini.
Docker: Version 17.09.0-ce-mac35 (19611)
Mac 10.13.1 (17B48)

Bug yang sama di sini. Saya harus menambahkan tiga baris ke / etc / hosts untuk menyelesaikan masalah ini.
127.0.0.1 localunixsocket
127.0.0.1 localunixsocket.lan
127.0.0.1 localunixsocket.local

Bug yang sama. Ini berhasil untuk saya.

$ 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

Saya menambahkan 127.0.0.1 localunixsocket dalam /etc/hosts dan berhasil untuk saya, terima kasih!
(tapi ini masih bug wtf)

Masih ada masalah di versi terbaru. Perbaikan di atas sepertinya tidak melakukan apa-apa untuk saya, pada titik tertentu itu menjadi sangat lambat sehingga macet. Solusi bagi saya adalah dengan sering-sering memulai ulang Docker untuk mac.

Dikonfirmasi bahwa 127.0.0.1 localunixsocket dalam /etc/hosts secara dramatis mempercepat, tolong perbaiki!

menambahkan 127.0.0.1 localunixsocket dalam /etc/hosts membantu. Saya menggunakan docker-compose version 1.18.0, build 8dd22a9

Solusi yang direkomendasikan @norbertsienkiewicz bekerja dengan sempurna untuk saya. Ini menurunkan waktu docker-compose up dari lebih dari 10 menit menjadi kurang dari satu menit (versi 1.18.0).

Saya sebenarnya lebih penasaran mengapa hal ini mulai terjadi. Tampaknya agak konyol bagi saya jika saya harus memodifikasi file host saya sebagai solusi untuk masalah yang baru-baru ini diperkenalkan dan telah dinyatakan sebagai "solusi".

Berikut adalah pelacakan balik yang menyebabkan pencarian DNS palsu:

  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)

Saya baru saja mengalami masalah ini setelah beralih dari nirkabel ke kabel. Kembali ke nirkabel dan semuanya baik-baik saja dengan dunia.

Apakah perubahan pada / etc / host ke mesin host atau container docker ??

File host mana yang akan dimodifikasi?

1. file host macOS?
2. VM Linux berfungsi sebagai host buruh pelabuhan?
3. Wadahnya sendiri?

Tidak yakin mengapa tetapi saya harus menghapus elemen domain lokal apa pun untuk membuatnya berfungsi.

/ etc / hosts:
127.0.0.1 localunixsocket

Jenius !!!