Was kostet die Laufzeitleistung eines Docker-Containers?

512

Ich möchte die Laufzeitleistungskosten eines Docker-Containers umfassend verstehen. Ich habe Hinweise darauf gefunden, dass das Netzwerk anekdotisch ~ 100µs langsamer ist .

Ich habe auch Hinweise darauf gefunden, dass die Laufzeitkosten "vernachlässigbar" und "nahe Null" sind, aber ich würde gerne genauer wissen, wie hoch diese Kosten sind. Im Idealfall möchte ich wissen, was Docker mit Leistungskosten abstrahiert und welche Dinge ohne Leistungskosten abstrahiert werden. Netzwerk, CPU, Speicher usw.

Wenn es Abstraktionskosten gibt, gibt es außerdem Möglichkeiten, die Abstraktionskosten zu umgehen. Zum Beispiel kann ich vielleicht eine Festplatte direkt oder virtuell in Docker mounten.

performance docker

— Luke Hoersten
quelle

Mögliches Duplikat von Gibt es eine Formel zur Berechnung des Overheads eines Docker-Containers?

— Golo Roden

@GoloRoden diese Frage ist ähnlich, aber nicht genau gleich. Ich suche nach Latenzkosten mit Gründen wie "Netzwerk wird durch eine zusätzliche Schicht geleitet", während die akzeptierte Antwort dieser Frage eher die Messung der Kosten für Container + App betrifft.

— Luke Hoersten

Okay, das stimmt. Ich habe meine enge Abstimmung zurückgezogen.

— Golo Roden

Ich bin froh, dass du es gepostet hast. Diese Frage kam bei meiner Suche nicht auf. Der Artikel über Messungen / Metriken ist sehr nützlich: blog.docker.io/2013/10/gathering-lxc-docker-containers-metrics

— Luke Hoersten

Dies ist eine gute Sitzung mit dem Titel "Linux-Container - NextGen-Virtualisierung für die Cloud", in der Leistungsmetriken durch Vergleichen von Docker, KVM-VM und Bare Metal

— erläutert werden

Antworten:

449

Ein ausgezeichnetes IBM-Forschungspapier aus dem Jahr 2014 „ Ein aktualisierter Leistungsvergleich von virtuellen Maschinen und Linux-Containern “ von Felter et al. bietet einen Vergleich zwischen Bare-Metal-, KVM- und Docker-Containern. Das allgemeine Ergebnis ist: Docker ist nahezu identisch mit der nativen Leistung und in jeder Kategorie schneller als KVM.

Die Ausnahme hiervon ist Dockers NAT. Wenn Sie die Portzuordnung verwenden (z. B. docker run -p 8080:8080), können Sie mit einem geringfügigen Latenzverlust rechnen, wie unten gezeigt. Sie können jetzt jedoch den Host-Netzwerkstapel (z. B. docker run --net=host) verwenden, wenn Sie einen Docker-Container starten, der mit der Native-Spalte identisch ist (wie in den Ergebnissen der Redis-Latenz weiter unten gezeigt).

Docker NAT Overhead

Sie führten auch Latenztests für einige bestimmte Dienste wie Redis durch. Sie können sehen, dass über 20 Client-Threads Docker NAT, dann KVM und dann eine grobe Verbindung zwischen Docker-Host / Native den höchsten Latenz-Overhead verursachen.

Latenz-Overhead für Docker Redis

Nur weil es ein wirklich nützliches Papier ist, hier einige andere Zahlen. Bitte laden Sie es für den vollständigen Zugriff herunter.

Werfen Sie einen Blick auf Disk I / O:

Docker vs. KVM vs. Native I / O-Leistung

Betrachten wir nun den CPU-Overhead:

Docker-CPU-Overhead

Nun einige Beispiele für Speicher (lesen Sie das Papier für Details, Speicher kann besonders schwierig sein):

Docker-Speichervergleich

— Hamy
quelle

Was die in der Zeitung angegebenen Linpack-Zahlen betrifft ... ehrlich gesagt, finde ich sie kaum zu glauben (nicht, dass ich nicht glaube, dass sie das sind, was Linpack emittiert hat, sondern dass ich nicht glaube, dass der Test wirklich nichts als Gleitkomma-Leistung als gemessen hat durchgeführt). Der Hauptaufwand von KVM liegt in den Hardware-Emulationskomponenten des Benutzerbereichs (die nur für Nicht-CPU- Hardware gelten). Speicher-Paging hat einen erheblichen Overhead ... aber rohes Gleitkomma? Ich möchte mir ansehen, was dort tatsächlich vor sich geht - vielleicht übermäßige Kontextwechsel.

— Charles Duffy

Korrektur für die aktuelle Docker CLI-Syntax: --net=host(zwei Striche) und -p 8080:8080(Kleinbuchstaben 'p') für NAT.

— bk0

Das zitierte IBM-Papier scheint sich zu sehr auf Netzwerk-E / A zu konzentrieren. Es werden niemals Kontextwechsel angesprochen. Wir haben uns LXC angesehen und mussten es aufgrund vermehrter nicht freiwilliger Kontextwechsel, die zu einer Verschlechterung der Antragsverarbeitung führten, schnell aufgeben.

— Eric

Ich bin auch neugierig auf Dateisystemoperationen - Verzeichnissuchen sind zum Beispiel ein Ort, an dem ich Overhead erwarten würde; Lese-, Schreib- und Suchvorgänge auf Blockebene (auf die sich die angegebenen Diagramme stark konzentrieren) sind dies nicht .

— Charles Duffy

Ich liebe Diagramme mit der gleichen Farbfarbe. Es ist so leicht zu unterscheiden

— Viktor Joras

104

Docker ist als solches keine Virtualisierung - stattdessen ist es eine Abstraktion zusätzlich zur Unterstützung des Kernels für verschiedene Prozessnamespaces, Gerätenamensräume usw.; Ein Namespace ist von Natur aus nicht teurer oder ineffizienter als ein anderer. Was Docker also tatsächlich zu einer Leistungsbeeinträchtigung bringt, hängt davon ab, was sich tatsächlich in diesen Namespaces befindet.

Die Auswahl von Docker in Bezug auf die Konfiguration von Namespaces für seine Container ist mit Kosten verbunden. Diese Kosten hängen jedoch alle direkt mit den Vorteilen zusammen. Sie können sie aufgeben. Dabei geben Sie jedoch auch den damit verbundenen Nutzen auf:

Layered-Dateisysteme sind teuer - genau die Kosten variieren mit jedem (und Docker unterstützt mehrere Backends) und Ihren Nutzungsmustern (das Zusammenführen mehrerer großer Verzeichnisse oder das Zusammenführen eines sehr tiefen Satzes von Dateisystemen ist besonders teuer), aber sie sind besonders teuer bin nicht frei Auf der anderen Seite hängt ein Großteil der Docker-Funktionalität - die Möglichkeit, Gäste auf Copy-on-Write-Weise von anderen Gästen abzubauen und die damit verbundenen Speichervorteile zu nutzen - von diesen Kosten ab.
DNAT wird im Maßstab teuer - bietet Ihnen jedoch den Vorteil, dass Sie das Netzwerk Ihres Gastes unabhängig von dem Ihres Hosts konfigurieren können und über eine praktische Schnittstelle verfügen, über die nur die gewünschten Ports zwischen diesen weitergeleitet werden können. Sie können dies durch eine Brücke zu einer physischen Schnittstelle ersetzen, aber auch hier den Vorteil verlieren.
Die Möglichkeit, jeden Software-Stack mit seinen Abhängigkeiten auf die bequemste Weise auszuführen - unabhängig von der Distribution, der libc und anderen Bibliotheksversionen des Hosts - ist ein großer Vorteil, muss jedoch gemeinsam genutzte Bibliotheken mehrmals laden (wenn ihre Versionen unterscheiden) hat die Kosten, die Sie erwarten würden.

Und so weiter. Wie stark sich diese Kosten tatsächlich auf Sie in Ihrer Umgebung auswirken - mit Ihren Netzwerkzugriffsmustern, Ihren Speicherbeschränkungen usw. - ist ein Punkt, für den es schwierig ist, eine allgemeine Antwort zu geben.

— Charles Duffy
quelle

Dies ist eine gute Antwort, aber ich suche nach spezifischeren Zahlen und Benchmarks. Ich bin mit den Kosten für Gruppen vertraut, aber Docker ist mehr als das, wie Sie bereits betont haben. Vielen Dank für die Antwort.

— Luke Hoersten

Sicher. Mein Punkt ist, dass alle allgemeinen Benchmarks, die Sie finden, nur sehr begrenzt auf eine bestimmte Anwendung anwendbar sind - aber das heißt nicht, dass ich nicht mit Leuten einverstanden bin, die versuchen, sie bereitzustellen, sondern lediglich, dass sie mit einem gehäuften Esslöffel Salz eingenommen werden sollten.

— Charles Duffy

Auf diese Weise könnte man sagen, dass KVM "keine Virtualisierung ist, sondern lediglich eine Abstraktion über x86-Aufrufe der virtuellen Technologie".

— Vad

@Vad, es gibt seit Jahrzehnten eine Konsensvereinbarung (zu den frühen Nicht-x86-Hardwareimplementierungen von IBM!), Dass die Bereitstellung von Abstraktion direkt auf der Hardwareschicht eindeutig Virtualisierung ist. Der Konsens für die Terminologie in Bezug auf den Namespace auf Kernel-Ebene ist erheblich fragmentierter - wir könnten jeweils auf Quellen verweisen, die unsere individuellen Ansichten bevorzugen -, aber ehrlich gesagt gibt es nützliche technische Unterschiede (sowohl in Bezug auf Sicherheits- als auch Leistungsmerkmale), die die Umstellung auf einen einzelnen Begriff verschleiern würde Daher halte ich meine Position, bis ein gegenteiliger Branchenkonsens erreicht ist.

— Charles Duffy

@LukeHoersten, ... richtig, es sind nicht die cgroups, die erhebliche Kosten verursachen, sondern vielmehr der Inhalt der Netzwerk- und Dateisystem-Namespaces. Aber wie viel diese Kosten sind , hängt fast vollständig ab , wie Docker konfiguriert ist - welche spezifischen Backends Sie verwenden. Bridging ist zum Beispiel viel, viel billiger als Dockers Standard-NAT. Der Performance-Overhead der verschiedenen Dateisystem-Backends variiert ebenfalls stark (und in einigen Fällen hängt der Overhead von den Verwendungsmustern ab; Overlayfs-Varianten können bei großen Verzeichnissen, die über mehrere Ebenen f / e geändert werden, viel teurer sein).

— Charles Duffy

Hier einige weitere Benchmarks für im Docker based memcached serverVergleich zu host native memcached serverTwemperf Benchmark - Tool https://github.com/twitter/twemperf mit 5000 Anschlüssen und 20k Verbindungsrate

Der Verbindungszeitaufwand für Docker-basiertes Memcached scheint mit dem obigen Whitepaper mit ungefähr der doppelten nativen Geschwindigkeit übereinzustimmen.

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

Hier sind die Bencmarks mit dem Memtier-Benchmark-Tool

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
quelle

Sie vergleichen zwei verschiedene Builds von Memcached, und auch eine davon in Docker, eine andere außerhalb von Docker, nicht wahr?

— San

Sind diese Ergebnisse mit Host-Netzwerken oder Bridge-Netzwerken in Docker?

— akaHuman

Mit solch großen Standards zeigen diese Messungen keine darstellbaren Datenavg 200.5 min 0.6 max 263.2 stddev 73.85

— Sergey Zhukov