Compose: UnixHTTPConnectionPool (host = 'localhost', port = None): Tempo de leitura esgotado. (ler tempo limite = 60)

tentei isso

export DOCKER_CLIENT_TIMEOUT=120
export COMPOSE_HTTP_TIMEOUT=120

e parece resolver o problema por enquanto

Outras soluções que as pessoas mencionaram neste tópico:

• Reinicie o Docker
• Aumente a CPU e a memória do Docker

Isso acontece se você desligar o WiFi? Pode estar relacionado a https://github.com/docker/docker-py/issues/1076.

Outra teoria, se o seu serviço tiver tty: True habilitado, poderia ser # 3106

Estou vendo exatamente o mesmo problema com a versão beta mais recente para Mac. Mesmo erro se eu executar docker-compose create

Isso pode estar relacionado a ter uma camada muito grande na imagem? (uma operação npm install muito longa que leva cerca de um minuto para ser achatada em uma camada quando o docker cria a imagem)

Também estamos vendo esse problema ao usar um arquivo docker compose com 6 contêineres [docker-compose versão 1.8.1, build 878cff1] no Windows e no mac [Versão 1.12.2-rc1-beta27 (build: 12496)
179c18cae7]

Aumentar os recursos disponíveis para docker parece reduzir a chance de isso acontecer (assim como estender as vars de tempo limite), mas nunca é eliminado.

Também temos algumas camadas grandes (240 MB é a maior, o comando de instalação do pacote principal) e estamos vinculando a um diretório host com 120 MB de arquivos em alguns contêineres.

De diferentes tentativas de contornar isso, descobri algo que pode lançar alguma luz sobre uma possível solução:

No início, meu cenário parecia um pouco assim:

app:
  build: .
  volumes:
    - ${PWD}:/usr/src
    - /usr/src/node_modules

Meu caminho montado incluía muitos diretórios com arquivos grandes e estáticos que eu realmente não precisava montados em termos de recarregamento de código. Então, acabei trocando por algo assim:

app:
  build: .
  volumes:
    - ${PWD}:/usr/src
    - /usr/src/static  # large files in a long dir structure
    - /usr/src/node_modules

Isso deixou de fora do tempo de execução a montagem de todos os meus grandes arquivos estáticos, o que fez o serviço iniciar muito mais rápido.

O que eu entendo disso é: quanto mais arquivos você monta, especialmente quanto maiores eles são (imagens nos MBs em vez de arquivos de origem nos Bs / KBs), o tempo de carregamento aumenta muito.

Espero que isto ajude

+1
Estou vendo esse problema de tempo limite todas as semanas, geralmente depois de um fim de semana ocioso, enquanto tentava me conectar aos contêineres, o tempo limite foi atingido ...
Tenho que encerrar o processo docker em execução e reiniciá-lo para solucionar o problema ....

+1
Isso acontece comigo toda vez que tento reiniciar os contêineres porque eles não estão mais respondendo depois de um dia. Não tenho certeza se o meu caso tem a ver com a montagem, pois estou tentando parar os recipientes.

Acontecendo com um conatiner nginx , Up 47 hours .
Docker para mac Version 17.03.1-ce-mac12 (17661) Channel: stable d1db12684b .

version: '2.1'
services:
  nginx:
    hostname: web
    extends:
      file: docker/docker-compose.yml
      service: nginx
    ports:
      - 80:80
      - 443:443
    volumes:
      - ./src:/var/www:ro

  php:
    build:
      dockerfile: "./docker/web/php/Dockerfile"
      context: "."
    volumes:
      - ./src:/var/www

$ docker-compose kill nginx
Killing project_nginx_1 ... 

ERROR: for project_nginx_1  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)
ERROR: An HTTP request took too long to complete. Retry with --verbose to obtain debug information.
If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60).

Obrigado @gvilarino , acredito que a montagem de arquivos grandes é a causa deste problema no meu servidor linux. Seu snippet pode ser uma solução alternativa se os arquivos grandes não forem necessários no contêiner.

No entanto, eu me pergunto por que a montagem é lenta no Docker? Talvez isso acione a cópia do disco? Mas por que?

@cherrot Eu não diria que sou extremamente proficiente no assunto, mas acredito que isso tenha a ver com o driver de armazenamento usado pelo Docker e como ele funciona internamente para manter as camadas em ordem. Use docker info para ver qual driver de armazenamento seu daemon está usando (provavelmente aufs , que é o mais lento) e dependendo do seu sistema operacional host, você pode alterá-lo para outra coisa ( overlay sendo uma escolha melhor, se compatível). Existem alternativas mais rápidas como LCFS, mas elas não são comercialmente suportadas pelo Docker, então você estará por conta própria lá.

Também estamos vendo esse tempo limite. Parece também devido aos volumes que estamos usando.

Precisamos de alguns contêineres para acessar alguns compartilhamentos de rede SMB. Portanto, montamos esses compartilhamentos no sistema host e os montamos no contêiner. Mas às vezes a comunicação entre o Windows Server e nosso host Linux é interrompida (consulte https://access.redhat.com/solutions/1360683) e isso está bloqueando o início ou a parada de nosso contêiner, que apenas expirou após algum tempo.

Eu não tenho uma correção ainda. Estou procurando um plug-in de volume que ofereça suporte a SMB ou que elimine o problema de comunicação de travamento no SMB. mas nenhuma solução real ainda.

FWIW: Para as pessoas que chegam aqui por meio do mecanismo de pesquisa e encontram sua solução, fui capaz de consertar isso simplesmente pelo método _você tentou desligá-lo e ligá-lo novamente? _; Reiniciei meu cliente Docker Mac OS.

+1 nisso, estou executando um teste de estresse em minha instância que executa 4 contêineres e o docker trava mesmo por docker ps -a então estou tentando reiniciar os contêineres, mas estou conseguindo
UnixHTTPConnectionPool(host='localhost', port=None): Read timed out e

Traceback (most recent call last):
  File "/usr/bin/docker-compose", line 9, in <module>
    load_entry_point('docker-compose==1.8.0', 'console_scripts', 'docker-compose')()
  File "/usr/lib/python2.7/dist-packages/compose/cli/main.py", line 61, in main
    command()
  File "/usr/lib/python2.7/dist-packages/compose/cli/main.py", line 113, in perform_command
    handler(command, command_options)
  File "/usr/lib/python2.7/contextlib.py", line 35, in __exit__
    self.gen.throw(type, value, traceback)
  File "/usr/lib/python2.7/dist-packages/compose/cli/errors.py", line 56, in handle_connection_errors
    log_timeout_error()
TypeError: log_timeout_error() takes exactly 1 argument (0 given)

Apenas se eu estiver reiniciando o serviço docker parece estar resolvido, alguma idéia?

+1

`Reiniciando web-jenkins_jenkins_1 ...

ERROR: for web-jenkins_jenkins_1 UnixHTTPConnectionPool (host = 'localhost', port = None): Tempo de leitura esgotado. (ler tempo limite = 130)
ERRO: uma solicitação HTTP demorou muito para ser concluída. Tente novamente com --verbose para obter informações de depuração.
Se você encontrar esse problema regularmente devido a condições de rede lentas, considere definir COMPOSE_HTTP_TIMEOUT para um valor mais alto (valor atual: 120).

eu reinicio o docker, ele resolveu. mas todos os dias eu preciso reiniciar

reiniciar o Docker funciona para mim.

1 reiniciar o docker funcionou para mim também.

Eu encontrei esse problema ao construir uma imagem Docker substancialmente grande e, em seguida, tentar enviá-la para um registro remoto. Reiniciar o Docker não era uma solução aplicável, mas a resposta de @bodaz resolveu para mim: https://github.com/docker/compose/issues/3927#issuecomment -245948736

@ rodrigo-brito - Estou recebendo esse erro há algum tempo e reiniciar o docker deamon tem resolvido o problema - não mais desde que adicionei outro serviço ao meu projeto.

Tenho o mesmo problema, mas tenho uma configuração bastante simples.
Tenho apenas um contêiner verdaccio 3 baseado em uma imagem com 164 MB de tamanho.
Isso é muito decepcionante: /

Estou usando um MBP Pro 13 de 2015

Aconteceu comigo por causa de um grande intervalo de porta, na verdade, cria uma regra por porta ....

Um simples sudo service docker restart resolve isso para mim de forma consistente sempre que ocorre.

Aconteceu comigo também, no meu caso docker-compose push (nem mesmo tentando executar o aplicativo) no Azure DevOps.

Minhas outras compilações não usam docker-compose, mas simplesmente docker push

Tirei a versão docker.io do kubuntu 18.04.1 do docker e instalei o docker-ce 18.09.0
O problema foi embora.

Acabei de converter a etapa de push docker-compose push individuais.

Estamos vendo esse tempo limite ao executar um contêiner via docker-compose ou por meio da biblioteca docker-py (atinge o tempo limite mesmo depois de aumentarmos o tempo limite para 2 minutos); no entanto, não vemos o erro quando executamos por meio do Docker CLI (o contêiner inicia instantaneamente). Também vemos o problema apenas em um servidor Linux CI e não em nossos Macs. Estamos trabalhando na construção de um exemplo reproduzível mínimo.

Tendo este problema com docker-compose kill em uma VM debian no host macos, instale direto do docker. (Docker versão 18.09.0, compilação 4d60db4)

Eu tive o mesmo erro ao iniciar o docker com log-driver: syslog quando a porta rsyslog não estava disponível.
Error starting container 0ba2fb9540ec6680001f90dce56ae3a04b831c8146357efaab79d4756253ec8b: UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

reiniciar o Docker funciona para mim.

@ rodrigo-brito reiniciar não é solução ...

Aconteceu comigo por causa de um grande intervalo de porta, na verdade, cria uma regra por porta ....

Exatamente a mesma coisa para mim. Após o erro, o daemon do docker continua a consumir memória até o esgotamento. Preciso systemctl stop docker antes que meu sistema morra. (Docker versão 18.09.3, compilação 774a1f4)

    ports:
      - "10000-20000:10000-20000"

O simples reinício do docker resolveu isso para mim ...

Parece que o problema ainda está presente nas versões recentes do docker-ce. Estou iniciando ~ 5 contêineres, com o lento tendo uma montagem de volume do docker que aponta para um compartilhamento NFS. Nenhum container expõe qualquer porta, alguém descobriu se este é um erro válido ( port=None parece suspeito)?

~~~
Cliente:
Versão: 18.09.5
Versão API: 1.39
Versão Go: go1.10.8
Git commit: e8ff056dbc
Construído: Qui. 11 de abril 04:44:28 2019
OS / Arch: linux / amd64
Experimental: falso

Servidor: Docker Engine - Comunidade
Motor:
Versão: 18.09.5
Versão da API: 1.39 (versão mínima 1.12)
Versão Go: go1.10.8
Git commit: e8ff056
Construído: Qui, 11 de abril, 04:10:53 2019
OS / Arch: linux / amd64
Experimental: falso
~~~

Adicionados mais resultados de --verbose . Não acho que haja nada de útil aqui, apenas diz por um longo tempo que alguma operação de criação de contêiner está esperando por um longo tempo. Aparentemente, está usando polling, pois a seguinte mensagem é impressa cerca de 1x / seg:

~compose.parallel.feed_queue: Pendente: set ()~

O localhost / port = Node é uma pista falsa, eu acho, já que a conexão é feita com docker.sock, então não é um erro nulo escondido em algum lugar. Acho que isso precisará ser rastreado dentro do docker, não que o tratamento docker-compose dessa solicitação aqui seja ideal.

Parece que falta algum tipo de id de solicitação no Docker-compose que poderia ser registrado, portanto, saberíamos qual solicitação está paralisada. Por exemplo, eu sei que meu contêiner api não pôde ser criado dentro do tempo limite, mas o log de solicitação não está ajudando em nada. Talvez outra pessoa possa adicionar algumas informações aqui:

~~~
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/containers/create?name=api-memcache HTTP / 1.1" 201 90
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker create_container -> {'Id': '22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f',
'Avisos': Nenhum}
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> Nenhum
compose.cli.verbose_proxy.proxy_callable: docker inspect_container <- ('22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f')
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network <- ('ba67095c5ea718af13a09798bc2f5ab24f5d0b54ce684b6f4cb248ab705df900', 'proxy', aliases = [Nenhum7, link_dressc = [Nenhum7] endereço_de_docal_de_logo7, 'ip706 = [None7, endereço_de_local_956', 'redis956 = [None7, endereço956', link_local_956 ',' redis956 '[Nenhum7, endereço956', link de 956 'local6,'
urllib3.connectionpool._make_request: http: // localhost: None "GET /v1.25/containers/22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f/json HTTP / 1.1" 200 Nenhum
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/containers/create?name=api HTTP / 1.1" 201 90
compose.cli.verbose_proxy.proxy_callable: docker create_container -> {'Id': '1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec',
'Avisos': Nenhum}
compose.cli.verbose_proxy.proxy_callable: docker inspect_container <- ('1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec')
compose.parallel.feed_queue: Pendente: set ()
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker inspect_container -> JSON ...
urllib3.connectionpool._make_request: http: // localhost: None "GET /v1.25/containers/1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec/json HTTP / 1.1" 200 Nenhum
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> Nenhum
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Nenhum
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network <- ('22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f', 'proxy')
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network <- ('7d81ef23610f1b8f7ac95837cbf6c9eef977b5b0846fea24be5c7054e471df39', 'proxy', aliases = [nenhum] ipdress6 = [None] link_dress6, 'ipdress6 = nenhum,' ipdress6 = nenhum, endereço_de_logo_de_logo], 'ipdress6104, 7 comentários,' ipdocal610, 'comentários6, nenhum],' addocal6104 comentários, 24be5c7054e471df39106, link6, 081df396108, 51fea24be5c7054e471df3910610 81, 51dfocal 10 link6, 81, 51dfocal101], 81, 51, 24be5c7054, 54, 51dfocal 10, 81, 81, 81, 51dfocal6 81 link de 81 links 81, 461docal6 81 linkfocal6, 51fea24be5c7054e471df39 ';
compose.cli.verbose_proxy.proxy_callable: docker inspect_container -> JSON ...
urllib3.connectionpool._make_request: http: // localhost : None "POST /v1.25/containers/create?name=api-comments-db HTTP / 1.1" 201 90
compose.cli.verbose_proxy.proxy_callable: docker start <- ('ba67095c5ea718af13a09798bc2f5ab24f5d0b54ce684b6f4cb248ab705df900')
compose.parallel.feed_queue: Pendente: set ()
compose.parallel.feed_queue: Pendente: set ()
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network <- ('1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec', 'proxy')
compose.cli.verbose_proxy.proxy_callable: docker create_container -> {'Id': 'ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af',
'Avisos': Nenhum}
urllib3.connectionpool._make_request: http: // localhost : None "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
urllib3.connectionpool._make_request: http: // localhost : None "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker inspect_container <- ('ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af')
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> Nenhum
compose.parallel.feed_queue: Pendente: set ()
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Nenhum
compose.cli.verbose_proxy.proxy_callable: janela de encaixe connect_container_to_network <- ( '22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f', 'proxy', pseudónimos = [ 'cache de memória', '22b774d0451c'], ipv4_address = Nenhum, ipv6_address = Nenhum, ligações = [], link_local_ips = Nenhum)
compose.parallel.feed_queue: Pendente: set ()
urllib3.connectionpool._make_request: http: // localhost : None "GET /v1.25/containers/ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af/json HTTP / 1.1" 200 Nenhum
urllib3.connectionpool._make_request: http: // localhost : None "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker start <- ('7d81ef23610f1b8f7ac95837cbf6c9eef977b5b0846fea24be5c7054e471df39')
compose.parallel.feed_queue: Pendente: set ()
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> Nenhum
compose.cli.verbose_proxy.proxy_callable: docker inspect_container -> JSON ...
urllib3.connectionpool._make_request: http: // localhost : None "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: janela de encaixe connect_container_to_network <- ( '1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec', 'proxy', pseudónimos = [ 'API', '1b67251d4941'], ipv4_address = Nenhum, ipv6_address = Nenhum, ligações = [], link_local_ips = Nenhum)
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network <- ('ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af', 'proxy')
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Nenhum
compose.cli.verbose_proxy.proxy_callable: docker start <- ('22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f')
compose.parallel.feed_queue: Pendente: set ()
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/networks/proxy/disconnect HTTP / 1.1" 200 0
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker disconnect_container_from_network -> Nenhum
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Nenhum
compose.cli.verbose_proxy.proxy_callable: estivador connect_container_to_network <- ( 'ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af', 'proxy', aliases = [ 'ff8c5cc4cb87', 'Comments-db'], ipv4_address = nenhum, ipv6_address = nenhum, ligações = [], link_local_ips = Nenhum)
compose.cli.verbose_proxy.proxy_callable: docker start <- ('1b67251d494199cfd4ba9855f20d41b6b0be8544757c2d5d416a90d044f4d0ec')
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/networks/proxy/connect HTTP / 1.1" 200 0
compose.cli.verbose_proxy.proxy_callable: docker connect_container_to_network -> Nenhum
compose.cli.verbose_proxy.proxy_callable: docker start <- ('ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af')
compose.parallel.feed_queue: Pendente: set ()
compose.parallel.feed_queue: Pendente: set ()
compose.parallel.feed_queue: Pendente: set ()
compose.parallel.feed_queue: Pendente: set ()
...
- omitido ~ 30 linhas
...
Criando comentários da API ... concluído
compose.cli.verbose_proxy.proxy_callable: docker start -> Nenhum
compose.parallel.parallel_execute_iter: Processamento concluído: ServiceName (project = 'api', service = 'comments', number = 1)
compose.parallel.feed_queue: Pendente: set ()
compose.parallel.parallel_execute_iter: Processamento concluído:
compose.parallel.feed_queue: Pendente: set ()
Criando api-memcache ... concluído
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/containers/22b774d0451c7aea118ba928a9a87177be09e63286f1d4eeaf009ddfe3c4c44f/start HTTP / 1.1" 204 0
compose.cli.verbose_proxy.proxy_callable: docker start -> Nenhum
compose.parallel.parallel_execute_iter: Processamento concluído: ServiceName (project = 'api', service = 'memcache', number = 1)
compose.parallel.feed_queue: Pendente: set ()
compose.parallel.parallel_execute_iter: Processamento concluído:
compose.parallel.feed_queue: Pendente: set ()
compose.parallel.feed_queue: Pendente: set ()
compose.parallel.feed_queue: Pendente: set ()
compose.parallel.feed_queue: Pendente: set ()
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/containers/ff8c5cc4cb87ba04aca3be5fcd3c6adcd08f5f4e6de5680857cbab37fd3027af/start HTTP / 1.1" 204 0
compose.cli.verbose_proxy.proxy_callable: docker start -> Nenhum
Criando api-comments-db ... concluído
compose.parallel.feed_queue: Pendente: set ()
compose.parallel.parallel_execute_iter: Processamento concluído:
compose.parallel.feed_queue: Pendente: set ()
compose.parallel.feed_queue: Pendente: set ()
compose.parallel.feed_queue: Pendente: set ()
compose.parallel.feed_queue: Pendente: set ()
compose.parallel.feed_queue: Pendente: set ()
- omitido ~ 15 linhas
Criando api-redis ... concluído
compose.parallel.feed_queue: Pendente: set ()
urllib3.connectionpool._make_request: http: // localhost: None "POST /v1.25/containers/ba67095c5ea718af13a09798bc2f5ab24f5d0b54ce684b6f4cb248ab705df900/start HTTP / 1.1" 204 0
compose.cli.verbose_proxy.proxy_callable: docker start -> Nenhum
compose.parallel.parallel_execute_iter: Processamento concluído: ServiceName (project = 'api', service = 'redis', number = 1)
compose.parallel.feed_queue: Pendente: set ()
compose.parallel.parallel_execute_iter: Processamento concluído:

compose.parallel.feed_queue: Pendente: set ()

- omitiu mais de 100 linhas
compose.parallel.parallel_execute_iter: Falha: ServiceName (projeto = 'api', serviço = 'api', número = 1)
compose.parallel.feed_queue: Pendente: set ()

ERROR: for api UnixHTTPConnectionPool (host = 'localhost', port = None): Tempo limite de leitura esgotado. (ler tempo limite = 60)
compose.parallel.parallel_execute_iter: Falha:
compose.parallel.feed_queue: Pendente: set ()

ERROR: for api UnixHTTPConnectionPool (host = 'localhost', port = None): Tempo limite de leitura esgotado. (ler tempo limite = 60)
compose.cli.errors.log_timeout_error: Uma solicitação HTTP demorou muito para ser concluída. Tente novamente com --verbose para obter informações de depuração.
Se você encontrar esse problema regularmente devido a condições de rede lentas, considere definir COMPOSE_HTTP_TIMEOUT para um valor mais alto (valor atual: 60).
~~~

@titpetric pode confirmar que também estou tendo esse problema.

IMHO, esse problema está no lado do docker, não no lado do docker-compose. Alguém deve ativar o registro de depuração no docker deamon e apontar os atrasos lá, e registrar um problema upstream. Não tenho certeza se alguém pode reproduzir isso facilmente sem isso.

Se alguém estiver disposto a investir tempo, sugiro replicar isso criando uma pasta totalmente carregada para uma montagem de volume (algo com cerca de 100.000 + arquivos / pastas deve servir), para ver se uma reprodução confiável do problema pode ser conseguida. É provável que o daemon do docker, ou a própria montagem do vínculo do kernel, armazene em cache alguns dos dados do inode de antemão. O que ... é lamentável.

Um tcpdump também pode confirmar isso no caso de um sistema de arquivos de rede (samba, nfs).

Exatamente o mesmo erro aqui

ERROR: for docker_async_worker__local_1  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=70)

ERROR: for docker_elasticsearch__local_1  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=70)

ERROR: for docker_web__local_1  UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=70)

A reinicialização do Docker também corrigiu para mim.

Reiniciar não é um conserto ...
Como evitar isso para sempre?

Enfrentando o mesmo problema. Erro abaixo para todos os contêineres docker dos pares da organização:

ERROR: for DNS UnixHTTPConnectionPool (host = 'localhost', port = None): Tempo de leitura esgotado. (ler tempo limite = 60)

É por causa de alguma incompatibilidade de porta ou atribuição no arquivo de composição?

Sim, constantemente encontrando esse problema sozinho. Concordo que reiniciar não é uma solução, mas nada mais parece funcionar: /

Apenas para sua informação, com meu caso apenas tentando novamente com docker-compose tende a resolver
isto. Acho que nunca reiniciei o dockerd, esse problema não persiste por
mim.

Na sexta-feira, 2 de agosto de 2019 às 13h39, Alex [email protected] escreveu:

Sim, constantemente encontrando esse problema sozinho. Eu concordo que reiniciar não é
uma solução, mas nada mais parece fazer o truque: /

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/docker/compose/issues/3927?email_source=notifications&email_token=AABY7EH4MVKGI56ZLEIUV5TQCQMHBA5CNFSM4CPDX2D2YY3PNVWWK3TUL52LHS4DFVREXGK43BOR3NZ6365NTWH664BVReqeqbbcbbcbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbvbvbvbvcvsu176 e Hbq .
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AABY7EA3NTUP5SNZRTFWFEDQCQMHBANCNFSM4CPDX2DQ
.

Também estou enfrentando este problema :(
UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

Mesmo problema aqui, reiniciar o Docker realmente trava. A única maneira é matar o Docker / ou reiniciar, mas essa não pode ser a solução.

@bitbrain yup, isso também vem acontecendo comigo há algum tempo.

Eu encontrei uma solução legal para isso (no MacOS)

O motivo pelo qual isso continuava acontecendo comigo era que Docker tinha pouca memória disponível.

Aumentar a memória de 2 GB para 8 GB resolveu o problema para mim.

Eu estava recebendo este erro após executar docker-compose up e docker-compose down algumas vezes. Eu tentei de tudo neste tópico. Aproveitando os recursos, reiniciando meu mac e reinstalando o Docker mais recente. Eu poderia fazer docker-compose up rodar novamente após reiniciar minha máquina, mas depois de repetir esses comandos algumas vezes, ele voltaria para este erro e eu não poderia fazer docker-compose up rodar.

Meu problema parece ter sido um conflito com outro serviço ( pow ) que estava vinculando à porta 80 quando um dos meus contêineres também estava vinculando à porta 80. Desinstalei o pow e não tive problemas por três dias.

3 anos abrem este tíquete e ainda não resolvido. O problema ainda ocorre mesmo se aumentarmos a conexão do cliente para 120 seg.

acabou de acontecer ao nosso servidor, problema aberto desde 2016, wtf

reiniciar o Docker funciona para mim.

@ rodrigo-brito reiniciar não é solução ...

meu homem.

Também experimentando isso agora. Selvagem.

O mesmo problema ocorre ao tentar docker-compose up ou docker-compose down. Eu resolvi isso parando o serviço mysqld e uma vez que o contêiner está ativo, eu inicio o mysql. A RAM está com 20% de uso.

Executando a Comunidade Docker Desktop para Mac v2.1.0.5

Eu encontrei esse problema e resolvi aumentando a quantidade de memória alocada para o Docker (e diminuindo a quantidade de CPUs).
Você pode fazer isso em Docker -> Preferências -> Avançado.
Passei de 8 CPUs e 2 GB de RAM para 4 CPUs e 16 GB de RAM para minha configuração específica.

Encontrei esse problema no Ubuntu Server 18.04 LTS. Reiniciar o docker não corrige o problema, da mesma forma definindo as variáveis ​​de ambiente. Alguma ideia?

@bpogodzinski , você tentou aumentar suas configurações de memória no Docker? Eu aumentei de 2 GB para 8 GB e isso resolveu o problema para mim.

De modo geral, esse problema parece ocorrer quando os contêineres exigem mais memória do que a memória disponível configurada no Docker e, em seguida, as coisas simplesmente travam.

Tivemos este problema e parece (para nós) estar relacionado a um volume nomeado com muitos arquivos. Não entendo, mas é o caso para nós que um docker-compose (editado por brevidade) que tem um serviço:

   serviceA:
        ...
        volumes:
            - serviceA_volume: /srvA/folder

   volumes:
       - serviceA_volume:

Dentro do Dockerfile para serviceA está o comando aparentemente inofensivo e ineficaz:

...
RUN mkdir -p /srvA/folder && chown -R user /srvA/folder
...

Observe que isso muda o proprietário recursivamente na pasta / srvA / que, no volume nomeado, é um grande sistema de arquivos com 100K de arquivos. No entanto, isso acontece quando a imagem é construída e essa pasta está vazia. Parece que o uso do volume nomeado herda as permissões do arquivo local da imagem e, a seguir, altera as permissões dos volumes nomeados.

Isso é uma vantagem e provavelmente não é o mesmo problema que todo mundo está tendo, mas foi o nosso problema (alternar a linha alterna o erro). O resultado é que esse tempo limite de http é provavelmente resultante de várias causas.

Reiniciar o docker nunca resolveu o problema no meu caso, aumentar os recursos definitivamente resolveu.

De acordo com minha experiência, esse problema geralmente surge em pequenas instâncias de nuvem onde a quantidade de RAM é perfeitamente adequada durante o funcionamento normal, mas se mostra insuficiente durante as operações docker ou docker-compose. Você poderia facilmente aumentar a RAM, mas provavelmente aumentaria drasticamente o custo de uma pequena VM.

Em cada caso, adicionar uma partição swap ou mesmo um arquivo swap resolveu esse problema para mim!

Ocorreu-me apenas em um pi de framboesa. Nenhum volume com grande quantidade de arquivos ou qualquer coisa.
Na verdade, eu venho criando esses recipientes naquela framboesa há um tempo (um ou dois anos, risos).
Não tenho certeza do que mudou.
Parece um pouco "inesperado".

O problema ainda aparece na área de trabalho do docker 2.2.0.3 em MacOs 🙁

Resolvi meu problema com os seguintes comandos:
docker volume prune
docker system prune
(apenas um desses comandos pode ser suficiente, mas não pode ser reproduzido no momento ...)

Resolvi meu problema com os seguintes comandos:
docker volume prune
docker system prune
(apenas um desses comandos pode ser suficiente, mas não pode ser reproduzido no momento ...)

A solução de @amaumont ajudou, embora eu ache que isso continuaria voltando com o tempo.
Como todo mundo já disse, reiniciar o docker não é uma solução adequada, é um bandaid.

Estamos tendo vários problemas com docker-compose também.

Depois de definir MaxSessions 500 em sshd_config (consulte # 6463), agora também obtemos intervalos de leitura.
Definir ambos os tempos limite para 120 segundos resolveu o problema para a próxima DOCKER_HOST=xxx<strong i="8">@yyy</strong> docker-compose up -d execução.

Durante a segunda execução, a carga da máquina chegou a 30 (sic!) Antes do comando docker-compose falhar devido a tempos limite. A reinicialização do docker não resolveu esse problema, nem mesmo temporariamente.
O servidor é uma instância AWS EC2 com CPU / disco / NetIO suficiente etc, o arquivo de composição inclui 1 traefik e 3 serviços com mailhog, então nada de especial aqui. Executar docker-compose up -d com o mesmo arquivo docker-compose.yml diretamente no servidor funciona de maneira confiável e conforme o esperado.
Executando com --verbose mostra mais de mil linhas consecutivas contendo compose.parallel.feed_queue: Pending: set() .

Vou tentar rsync o arquivo docker-compose para o servidor remoto e executar docker-compose diretamente nessa máquina como uma solução alternativa.

Para mim, ajudou apenas a reiniciar o docker.

Acontece com bastante frequência quando tento acessar meu registro privado a partir de pipelines de bitbucket. Funciona bem ao enviar de um PC local.
Reiniciar o docker pode ajudar por um tempo, no entanto, esse "enquanto" dura no máximo 10 min: c

atualiz. definir DOCKER_CLIENT_TIMEOUT e COMPOSE_HTTP_TIMEOUT pareceu ajudar, mas não sei por quanto tempo

Comecei a recebê-los desde que mudei para Docker Edge com Caching ativado

Isso tem acontecido de forma bastante consistente para mim desde que comecei a usar o Docker, 2 a 3 anos atrás. Depois de um contêiner estar em execução por um tempo, ele se torna um zumbi e todo o mecanismo do Docker precisa ser reiniciado para que as coisas voltem a responder. Isso parece algum tipo de vazamento de recursos, já que o tempo ocioso parece ser muito relevante para o comportamento vivenciado.

Se nenhum contêiner estiver em execução, ou se eles forem executados por um curto período, tudo parece estar funcionando bem por dias ou semanas. Mas assim que deixo um contêiner rodar por algumas horas, ele deixa de responder, tenho que forçá-lo a parar na linha de comando e qualquer tentativa de comunicação com docker ou docker-compose simplesmente falha com um tempo limite. Reiniciar é a única solução de trabalho.

Resultado de docker-compose version

docker-compose version 1.25.5, build 8a1c60f6
docker-py version: 4.1.0
CPython version: 3.7.5
OpenSSL version: OpenSSL 1.1.1f  31 Mar 2020

Resultado de docker version

Client: Docker Engine - Community
 Version:           19.03.8
 API version:       1.40
 Go version:        go1.12.17
 Git commit:        afacb8b
 Built:             Wed Mar 11 01:21:11 2020
 OS/Arch:           darwin/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.8
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.17
  Git commit:       afacb8b
  Built:            Wed Mar 11 01:29:16 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Resultado de docker-compose config

services:
  portal:
    container_name: developer_portal
    image: swedbankpay/jekyll-plantuml:1.3.8
    ports:
    - published: 4000
      target: 4000
    - published: 35729
      target: 35729
    volumes:
    - .:/srv/jekyll:rw
    - ./.bundle:/usr/local/bundle:rw
version: '3.7'

macOS Mojave 10.14.6.

Eu enfrentei o mesmo problema, até eu aumentei os recursos de 4 GB de RAM, troca de 1 GB para 6 GB de RAM, troca de 2 GB.

Eu também estou enfrentando o mesmo problema

também tendo o mesmo problema

Tenho enfrentado o mesmo problema no Ubuntu 18.04 LTS (8 GB de RAM) usando HTTPS.

Sou capaz de gerar contêineres com docker-compose up , porém, uma vez implantado, não consigo parar os contêineres com docker-compose down . Reiniciar o docker daemon ou reinicializar a VM provou ser ineficaz. Adicionar variáveis ​​de ambiente de tempo limite ( DOCKER_CLIENT_TIMEOUT , COMPOSE_HTTP_TIMEOUT ) também não fez nada.

Sou capaz de interagir e parar contêineres individualmente, posso inspecionar contêineres, anexar a eles e qualquer outra coisa, mas não posso pará-los ou eliminá-los usando o comando docker-compose .

A mensagem de erro é sempre a mesma:

msg: 'Error stopping project - HTTPSConnectionPool(host=[ommited], port=2376): Read timed out. (read timeout=120)

Eu estava tendo o mesmo problema quando tive o seguinte em meu docker-compose.yml:

logging:
      driver: "json-file"
      options:
        max-size: 100m
        max-file: 10

O erro desapareceu quando adicionei aspas em torno de "10". Isso é declarado na documentação que os valores para max-file e max-size devem ser string, mas ainda assim. A mensagem de erro é bastante enganosa.

Eu estava tendo o mesmo problema quando tive o seguinte em meu docker-compose.yml:

logging:
      driver: "json-file"
      options:
        max-size: 100m
        max-file: 10

O erro desapareceu quando adicionei aspas em torno de "10". Isso é declarado na documentação que os valores para max-file e max-size devem ser string, mas ainda assim. A mensagem de erro é bastante enganosa.

Você salva meu dia. Muito obrigado!

Eu estava tendo o mesmo problema quando tive o seguinte em meu docker-compose.yml:

logging:
      driver: "json-file"
      options:
        max-size: 100m
        max-file: 10

O erro desapareceu quando adicionei aspas em torno de "10". Isso é declarado na documentação que os valores para max-file e max-size devem ser string, mas ainda assim. A mensagem de erro é bastante enganosa.

Estou configurando o driver de registro no nível do daemon do docker. Estou usando fluentd como meu driver de registro, então, infelizmente, essa correção não funcionará para mim. = /

tentei isso

export DOCKER_CLIENT_TIMEOUT=120
export COMPOSE_HTTP_TIMEOUT=120

e parece resolver o problema por enquanto

Outras soluções que as pessoas mencionaram neste tópico:

• Reinicie o Docker
• Aumente a CPU e a memória do Docker

Bem, nada funcionou para mim, exceto a opção de tempo limite, parabéns para você.

Estou recebendo isso desde que comecei a usar um diretório montado NFS dentro de um dos meus contêineres. Esse diretório montado por NFS está em um link lento (em um local remoto que possui uma conexão de baixa largura de banda). Será esse o problema?

Estou experimentando isso com muita frequência no Mac, Docker 2.4.0.0, em dois projetos diferentes com configurações docker-compose.yml diferentes. Não me lembro de ter acontecido antes de ~ 1 semana atrás, quando eu atualizei para 2.4.0.0. Existe uma regressão?

Tentei aumentar o tempo limite para 600, aumentar a RAM para 16 GB e trocar para 4 GB, reiniciando o Docker, reiniciando todo o meu Macbook, nada parece funcionar, exceto tentar aleatoriamente de novo e de novo, então ocasionalmente funcionará. Mas então, da próxima vez que eu precisar reiniciar ou reconstruir um contêiner, o mesmo problema :(

Comecei a ver isso com 2.4.0.0 no Mac também. A solução alternativa para mim é reiniciar o docker, mas ele será executado novamente mais tarde.

O mesmo aqui! Com a atualização para 2.4.0, nossas configurações às vezes nem começam com os erros Read timed out. mencionados, às vezes apenas alguns contêineres são inicializados, outros apresentam esse erro. Já estou pensando em um downgrade!

Apenas para mencionar: esse problema afeta as configurações que usam compartilhamentos NFS e também os projetos que usam volumes montados "normais"

Mesmo problema aqui, também no mac e após a atualização 2.4.0. No momento, estou tentando se o downgrade ajuda.

Atualização: fazer o downgrade para a versão anterior, excluir o cache e reconstruir corrige o problema.

Também comecei a ver esse problema recentemente (Mac, 2.4.0.0), quando nunca o tinha visto antes. Executar docker image prune fez com que o problema desaparecesse por alguns dias, mas agora ele voltou novamente.

Também começou a ter frequentemente este erro de tempo limite desde a atualização 2.4.0 (no Mac OS Mojave 10.14.5)

Também vendo isso com maior frequência desde a atualização para Docker Desktop 2.4.0.0 (48506) no MacOS Catalina.

Tenho os mesmos problemas de tempo limite desde 2.4.0.0 no Mac OS. Eu nunca tive esse problema antes.
Tentei o edge build 2.4.1.0 (48583), mas ainda tenho o mesmo problema.

Eu tive o mesmo problema e a reinicialização do docker corrigiu para MacOs Catalina (10.15.5) e docker versão 2.4.0.0

Mesmo aqui, não tive o problema antes de atualizar para Docker desktop 2.4.0.0.
Reiniciar a área de trabalho do Docker funciona, mas é apenas uma solução alternativa.

O mesmo aqui, também começando com v2.4.0

Atualização: fazer o downgrade para a versão anterior, excluir o cache e reconstruir corrige o problema.

Vou tentar isso. Nem tenho certeza de como isso é feito. Presumo que seja desinstalando e baixando uma versão anterior.

Sim, desinstalei o 2.4 e baixei / reinstalei o 2.3. Agora que funciona, posso iniciar meus contêineres normalmente.
Peguei o 2.3 de lá: https://docs.docker.com/docker-for-mac/release-notes/#docker -desktop-community-2302

Sim, posso confirmar que fez a diferença para mim também. Definitivamente, a v2.4 é a culpada aqui de alguma forma.

Se você encontrar esse problema regularmente devido a condições de rede lentas, considere definir COMPOSE_HTTP_TIMEOUT para um valor mais alto (valor atual: 60).

Quão 1Gbps é uma rede lenta, exatamente?

O downgrade funcionou para mim também. Para aqueles que gerenciam o Docker via Homebrew

brew uninstall docker
brew install https://raw.githubusercontent.com/Homebrew/homebrew-cask/9da3c988402d218796d1f962910e1ef3c4fca1d3/Casks/docker.rb

Se você encontrar esse problema regularmente devido a condições de rede lentas, considere definir COMPOSE_HTTP_TIMEOUT para um valor mais alto (valor atual: 60).

Quão 1Gbps é uma rede lenta, exatamente?

No meu caso, isso aconteceu devido a uma unidade de rede montada em NFS.
A causa raiz da velocidade de rede "lenta" era o uso de NFS, não a velocidade do link físico.
Mas definitivamente mostra que há um problema na implementação e eu ficaria surpreso se a alteração de HTTP_TIMEOUT resolvesse isso.

O mesmo aqui. Lentidão significativa na criação do contêiner, resultando no erro de tempo limite de HTTP mencionado anteriormente no Docker para Mac v2.4. Definir COMPOSE_HTTP_TIMEOUT = 120 funcionou, mas a lentidão na criação do contêiner ainda é um novo problema. O downgrade para a v2.3 também corrige isso.

Posso confirmar o mesmo problema desde que instalei o Docker para Mac v2.4.
Também posso confirmar um aumento significativo no consumo de RAM e CPU mesmo em momentos ociosos, apenas com o daemon do Docker em execução. Mas acho que não tem nada a ver com o próprio pacote de composição.

Eu tenho esse mesmo problema. Desinstalei o 2.40 e instalei o 2.3 a partir do link mencionado por @ddesrousseaux e não tenho mais

https://docs.docker.com/docker-for-mac/release-notes/#docker -desktop-community-2302

Este problema ainda existe no Docker v. 2.4.3.0 .

Eu também fiz downgrade para 2.3 de 2.4 para contornar os enormes problemas de lentidão na versão 2.4. Fico feliz em fornecer quaisquer registros que possam ser úteis para depurar o que está acontecendo aqui.

Ecoando o acima, isso começou a acontecer em 2.4.2.x para mim. Algo mudou na atualização do 2.3.

Fiz alguns testes em um ambiente Linux e tive um problema semelhante. Eu instalei o binário docker-compose mais recente (v1.27.4) e tive o mesmo problema de tempo limite que vocês estão relatando.

Após o downgrade para 1.27.2, o mesmo disponível no Docker para Mac 2.3, o problema desapareceu.

Mesmo problema com a versão atual do Ubuntu 20.04.

Meu problema é que instalei docker e docker-compose com snap e apt. Desinstalei-os, reiniciei e segui as instruções oficiais de instalação em https://docs.docker.com/engine/install/ubuntu/ e https://docs.docker.com/compose/install/

Ainda estou tendo erros frequentes de tempo limite desde a atualização 2.4.0 que ainda não foram corrigidos no 2.5.0

Sim, o mesmo aqui. Estava funcionando bem para mim nos últimos 2 anos. Mas 2 meses atrás, de repente, sempre que eu quero uma instância e iniciar outro projeto docker, ele lança:
para apache UnixHTTPConnectionPool (host = 'localhost', port = None): Tempo de leitura esgotado.

Reiniciar o Docker corrige o problema. Mas é uma verdadeira dor quando tenho que alternar entre projetos várias vezes em 1 dia

Alcançando o mesmo problema desde 2,4, 300% da CPU o tempo todo, 2,5 não ajudou, rebaixado para 2,3 e tudo está bem. Este no último macbook com cpu i7 e 32g de RAM

Acabei de atualizar para a última versão do Docker para Mac (v2.5.0.1) e o problema parece estar resolvido.
Chega de UnixHTTPConnection erro e não chega a 100% de uso da CPU.

Não tenho certeza se alguém pode confirmar isso.

Como você conseguiu isso? Abrir o Docker no Mac e fazer "Check for Updates" ainda indica que tenho o mais recente, 2.4.2.0.

Acabei de atualizar para a última versão do Docker para Mac (v2.5.0.1) e o problema parece estar resolvido.
Chega de UnixHTTPConnection erro e não chega a 100% de uso da CPU.

Não tenho certeza se alguém pode confirmar isso.

Acabei de experimentar o problema na v2.5.0.1. Reiniciar o docker parece (pelo menos temporariamente) resolver o problema.

Como você conseguiu isso? Abrir o Docker no Mac e fazer "Check for Updates" ainda indica que tenho o mais recente, 2.4.2.0.

Não posso mostrar nenhuma captura de tela porque já atualizei, mas acho que você pode ter alguns problemas para obter atualizações do seu computador, já que há uma versão anterior v2.5.0 disponível há mais de uma semana.

Você pode verificar isso nas notas de versão do

Estou executando o Edge. Isso provavelmente explica tudo.

Pode confirmar que v2.5.0.1 é pelo menos um pouco melhor. Não obtive mais tempo limite a cada inicialização e ainda não o deparei com a atualização esta manhã. O tempo de inicialização do contêiner ainda parece muito mais lento do que 2.3, no entanto.

Editar: acabei de encontrar erros de tempo limite novamente, após cerca de 4 ou 5 reinicializações do meu projeto docker-compose. Também encontrou um novo erro com 2.5.0.1: Cannot start service <container name>: error while creating mount source path <local mount path>: mkdir <local mount path>: file exists

Pode confirmar que v2.5.0.1 é pelo menos um pouco melhor. Não obtive mais tempo limite a cada inicialização e ainda não o deparei com a atualização esta manhã. O tempo de inicialização do contêiner ainda parece muito mais lento do que 2.3, no entanto.

Editar: acabei de encontrar erros de tempo limite novamente, após cerca de 4 ou 5 reinicializações do meu projeto docker-compose. Também encontrou um novo erro com 2.5.0.1: Cannot start service <container name>: error while creating mount source path <local mount path>: mkdir <local mount path>: file exists

OK, ainda estou enfrentando alguns problemas com a versão 2.5.0.1. O uso da CPU ainda é muito alto em comparação com v2.3.x, e a velocidade também é muito lenta.

Alguém da equipe do Docker pode reconhecer e opinar sobre isso?

Deus, passaram 4 anos, esse problema ainda não foi resolvido, e isso acontece comigo o tempo todo