Qual è il costo delle prestazioni di runtime di un container Docker?

512

Mi piacerebbe comprendere a fondo il costo di runtime di un container Docker. Ho trovato i riferimenti al networking aneddoticamente più lento di ~ 100µs .

Ho anche riscontrato che i riferimenti al costo di runtime sono "trascurabili" e "vicini allo zero", ma vorrei sapere più precisamente quali sono tali costi. Idealmente mi piacerebbe sapere cosa Docker sta astrattando con un costo di prestazione e cose che sono astratte senza un costo di prestazione. Rete, CPU, memoria, ecc.

Inoltre, se ci sono costi di astrazione, ci sono modi per aggirare il costo di astrazione. Ad esempio, forse posso montare un disco direttamente contro virtualmente in Docker.

performance docker

— Luke Hoersten
fonte

possibile duplicato di Esiste una formula per calcolare l'overhead di un contenitore Docker?

— Golo Roden,

@GoloRoden quella domanda è simile ma non esattamente la stessa. Sto cercando i costi di latenza con motivi come "il networking viene passato attraverso un ulteriore livello", mentre la risposta accettata di quella domanda riguarda più la misurazione dei costi dell'app contenitore +.

— Luke Hoersten,

Ok, esatto. Ho ritirato il mio voto ravvicinato.

— Golo Roden,

Sono contento che tu l'abbia pubblicato però. Questa domanda non è emersa nella mia ricerca. L'articolo di misurazione / metrica è super utile: blog.docker.io/2013/10/gathering-lxc-docker-containers-metrics

— Luke Hoersten

Questa è una buona sessione intitolata "Contenitori Linux - Virtualizzazione NextGen per il cloud" che racconta le metriche delle prestazioni confrontando docker, KVM VM e bare metal: youtube.com/watch?v=a4oOAVhNLjU

— shawmzhu

Risposte:

449

Un eccellente documento di ricerca IBM del 2014 " Un confronto aggiornato delle prestazioni di macchine virtuali e container Linux " di Felter et al. fornisce un confronto tra contenitori bare metal, KVM e Docker. Il risultato generale è: Docker è quasi identico alle prestazioni native e più veloce di KVM in ogni categoria.

L'eccezione a questo è il NAT di Docker: se si utilizza il mapping delle porte (ad esempio, docker run -p 8080:8080), è possibile aspettarsi un hit minore in latenza, come mostrato di seguito. Tuttavia, ora è possibile utilizzare lo stack di rete host (ad es. docker run --net=host) Quando si avvia un contenitore Docker, che funzionerà in modo identico alla colonna nativa (come mostrato nei risultati di latenza Redis in basso).

Docker NAT overhead

Hanno anche eseguito test di latenza su alcuni servizi specifici, come Redis. Si può vedere che oltre 20 thread client, l'overhead di latenza più elevata va a Docker NAT, quindi a KVM, quindi a un legame approssimativo tra host / nativo Docker.

Docker Redis Latenza ambientale

Solo perché è un documento davvero utile, ecco alcune altre figure. Si prega di scaricarlo per l'accesso completo.

Dai un'occhiata a I / O su disco:

Docker vs. KVM vs. Performance I / O nativa

Ora osservando l'overhead della CPU:

Docker CPU Overhead

Ora alcuni esempi di memoria (leggi il documento per i dettagli, la memoria può essere più complicata):

Confronto della memoria Docker

— Hamy
fonte

Per quanto riguarda i numeri di linpack indicati nel documento ... francamente, li trovo difficili da credere (non che non creda che siano ciò che Linpack ha emesso, ma che non credo che il test non misurasse sinceramente nient'altro che prestazioni in virgola mobile come eseguita). Il principale sovraccarico di KVM è nei componenti di emulazione hardware dello spazio utente (che si applicano solo all'hardware senza CPU ); c'è un notevole sovraccarico nel paging della memoria ... ma in virgola mobile? Vorrei vedere cosa stava realmente succedendo lì - forse cambi di contesto eccessivi.

— Charles Duffy,

Correzione per la sintassi della CLI Docker corrente: --net=host(due trattini) e -p 8080:8080('p' minuscola) per NAT.

— bk0,

L'articolo citato IBM sembra troppo focalizzato sull'IO della rete. Non si rivolge mai ai cambi di contesto. Abbiamo esaminato LXC e abbiamo dovuto abbandonarlo rapidamente a causa dei maggiori cambi di contesto non volontari con conseguente degrado dell'elaborazione delle applicazioni.

— Eric,

Sono anche curioso delle operazioni del filesystem - le ricerche di directory, per esempio, sono un posto dove mi aspetto di vedere il sovraccarico; a livello di blocco legge, scrive e cerca (che le tabelle riportate si concentrano pesantemente su) non sono .

— Charles Duffy,

Adoro i grafici con lo stesso colore di tonalità. È così facile distinguere

— Viktor Joras

104

Docker non è la virtualizzazione, in quanto tale - invece, è un'astrazione in aggiunta al supporto del kernel per diversi spazi dei nomi dei processi, spazi dei nomi dei dispositivi, ecc .; uno spazio dei nomi non è intrinsecamente più costoso o inefficiente di un altro, quindi ciò che realmente fa sì che Docker abbia un impatto sulle prestazioni è una questione di ciò che è effettivamente in quegli spazi dei nomi.

Le scelte di Docker in termini di come configura gli spazi dei nomi per i suoi contenitori hanno dei costi, ma quei costi sono tutti direttamente associati ai vantaggi: puoi rinunciarli, ma nel farlo rinunci anche al vantaggio associato:

I filesystem a strati sono costosi: esattamente quali sono i costi variano a seconda di ciascuno (e Docker supporta più backend) e con i tuoi schemi di utilizzo (unire più directory di grandi dimensioni o un insieme molto profondo di filesystem sarà particolarmente costoso), ma essi non sei libero. D'altra parte, una grande quantità di funzionalità di Docker - essere in grado di generare ospiti da altri ospiti in modo copia-su-scrivere e ottenere impliciti vantaggi di archiviazione nello stesso - cavalca pagando questo costo.
DNAT diventa costoso su larga scala, ma ti dà il vantaggio di essere in grado di configurare la rete del tuo ospite indipendentemente da quella del tuo host e di avere una comoda interfaccia per inoltrare solo le porte che desideri tra di loro. Puoi sostituirlo con un bridge verso un'interfaccia fisica, ma, di nuovo, perdi il vantaggio.
Essere in grado di eseguire ogni stack software con le sue dipendenze installate nel modo più conveniente - indipendentemente dalla distribuzione dell'host, dalla libc e dalle altre versioni delle librerie - è un grande vantaggio, ma è necessario caricare più librerie condivise (quando le loro versioni differire) ha il costo che ti aspetteresti.

E così via. Quanto questi costi ti influenzino effettivamente nel tuo ambiente - con i tuoi schemi di accesso alla rete, i tuoi limiti di memoria, ecc. - è un elemento per il quale è difficile fornire una risposta generica.

— Charles Duffy
fonte

Questa è una buona risposta ma sto cercando numeri e benchmark più specifici. Ho familiarità con il costo dei cgroups ma Docker è più di questo, come hai sottolineato. Grazie mille per la risposta.

— Luke Hoersten,

Sicuro. Il mio punto è che qualsiasi benchmark generalizzato che trovi avrà un'applicabilità molto limitata a qualsiasi applicazione specifica - ma questo non vuol dire che non sono d'accordo con la gente che cerca di fornirli, ma semplicemente che dovrebbero essere presi con un cucchiaio colmo di sale.

— Charles Duffy,

In questo modo si potrebbe dire che KVM "non è una virtualizzazione, è semplicemente un'astrazione in cima alle chiamate della tecnologia virtuale x86".

— Vad

@Vad, c'è accordo di consenso, risalente a decenni fa (alle prime implementazioni hardware non x86 di IBM!), Che fornire astrazione direttamente sul livello hardware è una virtualizzazione inequivocabile. Il consenso per la terminologia relativa allo spazio dei nomi a livello di kernel è considerevolmente più frammentato - ognuno di noi potrebbe puntare a fonti che favoriscono le nostre opinioni individuali - ma francamente, ci sono utili distinzioni tecniche (sia in termini di sicurezza che di caratteristiche prestazionali) che passare a un singolo termine sarebbe oscuro , quindi mantengo la mia posizione fino a quando e se non viene raggiunto il consenso contrario del settore.

— Charles Duffy,

@LukeHoersten, ... giusto, non sono i cgroups ad avere un costo significativo, è molto più il contenuto della rete e gli spazi dei nomi del filesystem. Ma quanto costano questi costi dipende quasi interamente dalla configurazione di Docker - quali specifici backend stai usando. Il ponte è molto, molto più economico del NAT predefinito di Docker, per esempio; e anche l'overhead delle prestazioni dei vari backend del filesystem varia in modo selvaggio (e in alcuni casi, la quantità di overhead dipende dai modelli di utilizzo; le varianti di overlayfs possono essere molto più costose con grandi directory modificate attraverso più livelli f / e).

— Charles Duffy,

Ecco alcuni altri parametri di riferimentoDocker based memcached server rispetto host native memcached serverall'utilizzo dello strumento di benchmark Twemperf https://github.com/twitter/twemperf con 5000 connessioni e velocità di connessione 20k

Il sovraccarico del tempo di connessione per memcached basato su docker sembra concordare con il white paper sopra a circa due volte la velocità nativa.

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

Ecco i segni distintivi che utilizzano lo strumento di riferimento memtier

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

Confrontano due diverse build di memcached, e anche una di esse nella finestra mobile, altre al di fuori della finestra mobile, no?

— San

Questi risultati sono con reti host o bridge in docker?

— aka Human

Con tali grandi stddev queste misurazioni non mostrano dati rappresentabiliavg 200.5 min 0.6 max 263.2 stddev 73.85

— Sergey Zhukov,