Qual é o custo de desempenho de tempo de execução de um contêiner Docker?

512

Eu gostaria de entender de maneira abrangente o custo de desempenho em tempo de execução de um contêiner Docker. Eu encontrei referências a redes anedoticamente sendo ~ 100µs mais lentas .

Também achei referências ao custo em tempo de execução "desprezível" e "próximo de zero", mas gostaria de saber com mais precisão quais são esses custos. Idealmente, eu gostaria de saber o que o Docker está abstraindo com um custo de desempenho e as coisas abstratas sem um custo de desempenho. Rede, CPU, memória, etc.

Além disso, se houver custos de abstração, existem maneiras de contornar o custo de abstração. Por exemplo, talvez eu possa montar um disco diretamente versus virtualmente no Docker.

performance docker

— Luke Hoersten
fonte

possível duplicata de Existe uma fórmula para calcular a sobrecarga de um contêiner do Docker?

— Golo Roden

@GoloRoden essa pergunta é semelhante, mas não exatamente a mesma. Estou procurando custos de latência com motivos como "a rede está sendo passada por uma camada extra", enquanto a resposta aceita dessa pergunta é mais sobre como medir os custos do aplicativo container +.

— Luke Hoersten

Ok, está certo. Eu retirei meu voto próximo.

— Golo Roden

Ainda bem que você postou. Essa pergunta não apareceu na minha pesquisa. O artigo de medição / métricas é super útil: blog.docker.io/2013/10/gathering-lxc-docker-containers-metrics

— Lucas Hoersten

Esta é uma sessão boa intitulado "Linux Containers - NextGen Virtualization for Cloud" dizendo métricas de desempenho, comparando janela de encaixe, KVM VM e nu metal: youtube.com/watch?v=a4oOAVhNLjU

— shawmzhu

Respostas:

449

Um excelente artigo de pesquisa da IBM para 2014 “ Uma comparação atualizada de desempenho de máquinas virtuais e contêineres Linux ” de Felter et al. fornece uma comparação entre contêineres bare metal, KVM e Docker. O resultado geral é: O Docker é quase idêntico ao desempenho nativo e mais rápido que o KVM em todas as categorias.

A exceção é o NAT do Docker - se você usar o mapeamento de portas (por exemplo, docker run -p 8080:8080), poderá esperar um pequeno acerto na latência, como mostrado abaixo. No entanto, agora você pode usar a pilha de rede do host (por exemplo, docker run --net=host) ao iniciar um contêiner do Docker, que funcionará de maneira idêntica à coluna Nativa (como mostrado nos resultados de latência do Redis, abaixo).

Sobrecarga de NAT do Docker

Eles também executaram testes de latência em alguns serviços específicos, como o Redis. Você pode ver que, acima de 20 encadeamentos do cliente, a sobrecarga de latência mais alta passa pelo NAT do Docker, depois pelo KVM e, então, um vínculo aproximado entre o host / nativo do Docker.

Sobrecarga de latência de redis do Docker

Só porque é um artigo realmente útil, aqui estão algumas outras figuras. Faça o download para obter acesso completo.

Analisando E / S de disco:

Docker vs. KVM vs. desempenho de E / S nativa

Agora, olhando para a sobrecarga da CPU:

Sobrecarga da CPU do Docker

Agora, alguns exemplos de memória (leia o artigo para obter detalhes, a memória pode ser mais complicada):

Comparação de memória do Docker

— Hamy
fonte

Quanto aos números de linpack fornecidos no artigo ... francamente, acho difícil acreditar (não que eu não acredite que eles sejam o que o linpack emitiu, mas que não acredite que o teste estava realmente medindo nada além de desempenho de ponto flutuante como realizada). A principal sobrecarga do KVM está nos componentes de emulação de hardware do espaço do usuário (que se aplicam apenas ao hardware sem CPU ); há uma sobrecarga significativa em torno da paginação de memória ... mas ponto flutuante bruto? Eu gostaria de ver o que realmente estava acontecendo lá - talvez alternâncias excessivas de contexto.

— Charles Duffy

Correção da sintaxe atual da CLI do Docker: --net=host(dois traços) e -p 8080:8080(minúsculas 'p') para NAT.

— bk0

O artigo IBM citado parece muito focado nas E / S da rede. Ele nunca aborda opções de contexto. Analisamos o LXC e tivemos que abandoná-lo rapidamente devido ao aumento das alternâncias de contexto não voluntárias, resultando no processamento de aplicativos degradado.

— Eric

Também estou curioso sobre as operações do sistema de arquivos - as pesquisas de diretório, por exemplo, são um lugar onde eu esperaria ver sobrecarga; leituras, gravações e pesquisas em nível de bloco (nas quais os gráficos fornecidos se concentram fortemente) não são .

— Charles Duffy

Adoro gráficos com a mesma cor de tonalidade. É tão fácil distinguir

— Viktor Joras

104

O Docker não é virtualização, como tal - em vez disso, é uma abstração sobre o suporte do kernel a diferentes espaços de nomes de processos, espaços de nomes de dispositivos, etc .; um espaço de nomes não é inerentemente mais caros ou ineficientes do que o outro, então o que realmente faz Docker ter um impacto no desempenho é uma questão do que é realmente em esses espaços para nome.

As opções do Docker em termos de como ele configura os namespaces para seus contêineres têm custos, mas todos esses custos estão diretamente associados aos benefícios - você pode desistir deles, mas ao fazê-lo, você também renuncia ao benefício associado:

Os sistemas de arquivos em camadas são caros - exatamente os custos variam de acordo com cada um (e o Docker suporta vários back-end) e com os padrões de uso (mesclar vários diretórios grandes ou mesclar um conjunto muito profundo de sistemas de arquivos será particularmente caro), mas eles não é livre. Por outro lado, grande parte da funcionalidade do Docker - poder criar convidados de outros convidados de maneira copiar-sobre-gravar e obter as vantagens de armazenamento implícitas no mesmo - é paga pelo custo.
O DNAT fica caro em escala - mas oferece o benefício de poder configurar a rede de seus convidados independentemente da rede do seu host e ter uma interface conveniente para encaminhar apenas as portas que você deseja entre elas. Você pode substituir isso por uma ponte para uma interface física, mas, novamente, perca o benefício.
Ser capaz de executar cada pilha de software com suas dependências instaladas da maneira mais conveniente - independente da distribuição do host, libc e outras versões da biblioteca - é um grande benefício, mas é necessário carregar bibliotecas compartilhadas mais de uma vez (quando suas versões diferir) tem o custo que você esperaria.

E assim por diante. Quanto esses custos realmente afetam você em seu ambiente - com seus padrões de acesso à rede, restrições de memória etc. - é um item para o qual é difícil fornecer uma resposta genérica.

— Charles Duffy
fonte

Esta é uma boa resposta, mas estou procurando números e referências mais específicos. Estou familiarizado com o custo dos cgroups, mas o Docker é mais do que isso, como você apontou. Muito obrigado pela resposta.

— Luke Hoersten

Certo. O que quero dizer é que quaisquer benchmarks generalizados que você encontrar terão aplicabilidade muito limitada a qualquer aplicativo específico - mas isso não quer dizer que eu não concorde com as pessoas que tentam fornecê-los, mas apenas que eles devem ser tomados com uma colher de sopa cheia de sal.

— Charles Duffy

Dessa maneira, você poderia dizer que o KVM "não é uma virtualização, é simplesmente uma abstração além das chamadas de tecnologia virtual x86".

— Vad

@Vad, existe um consenso, que remonta décadas (às primeiras implementações de hardware não x86 da IBM!), Que fornecer abstração diretamente na camada de hardware é uma virtualização inequívoca. O consenso quanto à terminologia em torno do espaçamento de nomes no nível do kernel é consideravelmente mais fragmentado - poderíamos apontar fontes que favorecem nossas visões individuais - mas, francamente, existem distinções técnicas úteis (em torno das características de segurança e desempenho) que a mudança para um único termo ocultaria , então estou mantendo minha posição até e, a menos que seja alcançado um consenso contrário do setor.

— Charles Duffy

@LukeHoersten, ... certo, não são os cgroups que têm um custo significativo, são muito mais o conteúdo dos namespaces da rede e do sistema de arquivos. Mas quanto custam esses custos depende quase inteiramente de como o Docker está configurado - quais back-end específicos você está usando. A ponte é muito, muito mais barata que o NAT padrão do Docker, por exemplo; e a sobrecarga de desempenho dos vários sistemas de arquivos também varia muito (e, em alguns casos, a quantidade de sobrecarga depende dos padrões de uso; as variantes overlayfs podem ser muito mais caras com grandes diretórios modificados por várias camadas f / e).

— Charles Duffy

Aqui está mais alguns benchmarks de Docker based memcached servercomparação host native memcached serverusando a ferramenta de benchmark Twemperf https://github.com/twitter/twemperf com 5000 conexões e 20k taxa de conexão

O tempo de conexão excedido para o memcached baseado no docker parece concordar com o whitepaper acima, aproximadamente à velocidade nativa duas vezes.

Twemperf Docker Memcached

Connection rate: 9817.9 conn/s
Connection time [ms]: avg 341.1 min 73.7 max 396.2 stddev 52.11
Connect time [ms]: avg 55.0 min 1.1 max 103.1 stddev 28.14
Request rate: 83942.7 req/s (0.0 ms/req)
Request size [B]: avg 129.0 min 129.0 max 129.0 stddev 0.00
Response rate: 83942.7 rsp/s (0.0 ms/rsp)
Response size [B]: avg 8.0 min 8.0 max 8.0 stddev 0.00
Response time [ms]: avg 28.6 min 1.2 max 65.0 stddev 0.01
Response time [ms]: p25 24.0 p50 27.0 p75 29.0
Response time [ms]: p95 58.0 p99 62.0 p999 65.0

Twemperf Centmin Mod Memcached

Connection rate: 11419.3 conn/s
Connection time [ms]: avg 200.5 min 0.6 max 263.2 stddev 73.85
Connect time [ms]: avg 26.2 min 0.0 max 53.5 stddev 14.59
Request rate: 114192.6 req/s (0.0 ms/req)
Request size [B]: avg 129.0 min 129.0 max 129.0 stddev 0.00
Response rate: 114192.6 rsp/s (0.0 ms/rsp)
Response size [B]: avg 8.0 min 8.0 max 8.0 stddev 0.00
Response time [ms]: avg 17.4 min 0.0 max 28.8 stddev 0.01
Response time [ms]: p25 12.0 p50 20.0 p75 23.0
Response time [ms]: p95 28.0 p99 28.0 p999 29.0

Aqui estão as referências básicas usando a ferramenta de referência mais importante

memtier_benchmark docker Memcached

4         Threads
50        Connections per thread
10000     Requests per thread
Type        Ops/sec     Hits/sec   Misses/sec      Latency       KB/sec
------------------------------------------------------------------------
Sets       16821.99          ---          ---      1.12600      2271.79
Gets      168035.07    159636.00      8399.07      1.12000     23884.00
Totals    184857.06    159636.00      8399.07      1.12100     26155.79

memtier_benchmark Centmin Mod Memcached

4         Threads
50        Connections per thread
10000     Requests per thread
Type        Ops/sec     Hits/sec   Misses/sec      Latency       KB/sec
------------------------------------------------------------------------
Sets       28468.13          ---          ---      0.62300      3844.59
Gets      284368.51    266547.14     17821.36      0.62200     39964.31
Totals    312836.64    266547.14     17821.36      0.62200     43808.90

— p4guru
fonte

Eles comparam duas construções diferentes do memcached e também uma delas na janela de encaixe, outra fora da janela de encaixe, não são?

— san

Esses resultados são com redes de host ou redes de ponte no docker?

— akaHuman

Com tais grandes stddevs essas medições não mostram quaisquer dados representávelavg 200.5 min 0.6 max 263.2 stddev 73.85

— Sergey Zhukov