Quel est le coût de performance d'exécution d'un conteneur Docker?

512

Je voudrais comprendre de manière approfondie le coût de performance d'exécution d'un conteneur Docker. J'ai trouvé des références à la mise en réseau anecdotique étant ~ 100µs plus lente .

J'ai également trouvé des références au coût d'exécution "négligeable" et "proche de zéro" mais j'aimerais savoir plus précisément quels sont ces coûts. Idéalement, j'aimerais savoir ce que Docker fait avec un coût de performance et les choses qui sont abstraites sans coût de performance. Réseaux, CPU, mémoire, etc.

De plus, s'il y a des coûts d'abstraction, existe-t-il des moyens de contourner le coût d'abstraction. Par exemple, je peux peut-être monter un disque directement contre virtuellement dans Docker.

performance docker

— Luke Hoersten
source

doublon possible de Y a

— Golo Roden

@GoloRoden cette question est similaire mais pas exactement la même. Je recherche des coûts de latence pour des raisons telles que "la mise en réseau passe par une couche supplémentaire" alors que la réponse acceptée à cette question concerne davantage la mesure des coûts du conteneur + de l'application.

— Luke Hoersten

D'accord, c'est vrai. J'ai rétracté mon vote serré.

— Golo Roden

Je suis content que vous l'ayez posté. Cette question n'est pas venue dans ma recherche. L'article sur les mesures / métriques est super utile: blog.docker.io/2013/10/gathering-lxc-docker-containers-metrics

— Luke Hoersten

Il s'agit d'une bonne session intitulée "Conteneurs Linux - NextGen Virtualization for Cloud" expliquant les mesures de performances en comparant Docker, KVM VM et bare metal: youtube.com/watch?v=a4oOAVhNLjU

— shawmzhu

Réponses:

449

Un excellent document de recherche IBM 2014 « Une comparaison des performances mise à jour des machines virtuelles et des conteneurs Linux » par Felter et al. fournit une comparaison entre les conteneurs bare metal, KVM et Docker. Le résultat général est: Docker est presque identique aux performances natives et plus rapide que KVM dans toutes les catégories.

L'exception à cela est le NAT de Docker - si vous utilisez le mappage de port (par exemple, docker run -p 8080:8080), vous pouvez vous attendre à un impact mineur dans la latence, comme indiqué ci-dessous. Cependant, vous pouvez désormais utiliser la pile du réseau hôte (par exemple, docker run --net=host) lors du lancement d'un conteneur Docker, qui fonctionnera de manière identique à la colonne Native (comme indiqué dans les résultats de latence Redis plus bas).

Overhead NAT Docker

Ils ont également effectué des tests de latence sur quelques services spécifiques, tels que Redis. Vous pouvez voir qu'au-dessus de 20 threads client, la surcharge de latence la plus élevée va Docker NAT, puis KVM, puis un lien approximatif entre Docker hôte / natif.

Docker Redis Latency Overhead

Juste parce que c'est un document vraiment utile, voici quelques autres chiffres. Veuillez le télécharger pour un accès complet.

Jetez un œil aux E / S disque:

Docker contre KVM contre performances d'E / S natives

Examinons maintenant les frais généraux du processeur:

Docker CPU Overhead

Maintenant, quelques exemples de mémoire (lisez le document pour plus de détails, la mémoire peut être très compliquée):

Comparaison de la mémoire Docker

— Hamy
source

Quant aux numéros de linpack donnés dans le papier ... franchement, je les trouve difficiles à croire (pas que je ne crois pas que ce soit ce que linpack a émis, mais que je ne crois pas que le test ne mesurait vraiment que des performances en virgule flottante comme réalisée). Le surcoût majeur de KVM réside dans les composants d'émulation matérielle de l'espace utilisateur (qui s'appliquent uniquement au matériel non CPU ); il y a une surcharge importante autour de la pagination de la mémoire ... mais en virgule flottante brute? Je voudrais regarder ce qui se passait réellement là-bas - peut-être des changements de contexte excessifs.

— Charles Duffy

Correction de la syntaxe Docker CLI actuelle: --net=host(deux tirets) et -p 8080:8080(minuscule 'p') pour NAT.

— bk0

Le document IBM cité semble trop axé sur les E / S réseau. Il ne traite jamais les changements de contexte. Nous avons examiné LXC et avons dû l'abandonner rapidement en raison de l'augmentation des changements de contexte non volontaires entraînant une dégradation du traitement des applications.

— Eric

Je suis également curieux au sujet des opérations du système de fichiers - les recherches de répertoire, par exemple, sont un endroit où je m'attendrais à voir des frais généraux; les lectures, les écritures et les recherches au niveau du bloc (sur lesquelles les graphiques donnés se concentrent fortement) ne le sont pas .

— Charles Duffy

J'adore les tableaux avec la même couleur de nuance. Il est si facile de distinguer

— Viktor Joras

105

Docker n'est pas la virtualisation en tant que telle - c'est plutôt une abstraction en plus de la prise en charge du noyau pour différents espaces de noms de processus, espaces de noms de périphériques, etc. un espace de noms n'est pas intrinsèquement plus cher ou inefficace qu'un autre, donc ce qui fait réellement Docker avoir un impact sur les performances est une question de ce qui est réellement dans ces espaces de noms.

Les choix de Docker en termes de configuration des espaces de noms pour ses conteneurs ont des coûts, mais ces coûts sont tous directement associés aux avantages - vous pouvez les abandonner, mais ce faisant, vous renoncez également aux avantages associés:

Les systèmes de fichiers en couches sont chers - exactement ce que les coûts varient selon chacun (et Docker prend en charge plusieurs backends), et avec vos modèles d'utilisation (la fusion de plusieurs grands répertoires ou la fusion d'un ensemble très complet de systèmes de fichiers sera particulièrement coûteuse), mais ils ne sont pas libres. D'un autre côté, une grande partie des fonctionnalités de Docker - être en mesure de créer des invités à partir d'autres clients d'une manière copie sur écriture, et obtenir les avantages de stockage implicites en la matière - coûtent ce coût.
DNAT coûte cher à grande échelle - mais vous offre l'avantage de pouvoir configurer la mise en réseau de vos invités indépendamment de celle de votre hôte et d'avoir une interface pratique pour transférer uniquement les ports que vous souhaitez entre eux. Vous pouvez remplacer cela par un pont vers une interface physique, mais encore une fois, perdez l'avantage.
Être capable d'exécuter chaque pile logicielle avec ses dépendances installées de la manière la plus pratique - indépendamment de la distribution de l'hôte, de la libc et des autres versions de bibliothèque - est un grand avantage, mais nécessite de charger les bibliothèques partagées plus d'une fois (lorsque leurs versions différer) a le coût que vous attendez.

Et ainsi de suite. Dans quelle mesure ces coûts vous affectent réellement dans votre environnement - avec vos modèles d'accès au réseau, vos contraintes de mémoire, etc. - est un élément pour lequel il est difficile de fournir une réponse générique.

— Charles Duffy
source

C'est une bonne réponse mais je recherche des chiffres et des repères plus spécifiques. Je connais le coût des cgroups mais Docker est plus que cela comme vous l'avez souligné. Merci beaucoup pour la réponse.

— Luke Hoersten

Sûr. Mon point est que tous les repères généralisés que vous trouverez seront d'une applicabilité très limitée à une application spécifique - mais cela ne veut pas dire que je suis en désaccord avec les gens qui essaient de les fournir, mais simplement qu'ils doivent être pris avec une cuillère à soupe de sel.

— Charles Duffy

De cette manière, vous pourriez dire que KVM "n'est pas une virtualisation, c'est simplement une abstraction en plus des appels de technologie virtuelle x86".

— Vad

@Vad, il y a un consensus, remontant des décennies (aux premières implémentations matérielles non x86 d'IBM!), Selon lequel fournir l'abstraction directement sur la couche matérielle est une virtualisation sans ambiguïté. Le consensus pour la terminologie autour de l'espace de noms au niveau du noyau est considérablement plus fragmenté - nous pourrions chacun pointer vers des sources favorisant nos opinions individuelles - mais franchement, il existe des distinctions techniques utiles (autour des caractéristiques de sécurité et de performances) que le passage à un seul terme obscurcirait. , donc je maintiens ma position jusqu'à ce qu'un consensus contraire de l'industrie soit atteint.

— Charles Duffy

@LukeHoersten, ... à droite, ce ne sont pas les groupes de contrôle qui ont un coût important, c'est bien plus le contenu des espaces de noms du réseau et du système de fichiers. Mais le montant de ces coûts dépend presque entièrement de la configuration de Docker - des backends spécifiques que vous utilisez. Le pontage est beaucoup, beaucoup moins cher que le NAT par défaut de Docker, par exemple; et la surcharge des performances des divers systèmes de fichiers varie également énormément (et dans certains cas, la quantité de surcharge dépend des modèles d'utilisation; les variantes de superposition peuvent être beaucoup plus chères avec de gros répertoires modifiés via plusieurs couches f / e).

— Charles Duffy du

Voici quelques références supplémentaires par Docker based memcached serverrapport à l' host native memcached serverutilisation de l'outil de référence Twemperf https://github.com/twitter/twemperf avec 5000 connexions et un taux de connexion de 20k

La surcharge de temps de connexion pour les memcaches basés sur les dockers semble être en accord avec le livre blanc ci-dessus à environ deux fois la vitesse native.

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

Voici les bencmarks en utilisant l'outil de benchmark 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
source

Ils comparent deux versions différentes de memcached, et aussi l'une d'elles dans docker, l'autre en dehors de docker, n'est-ce pas?

— san

Ces résultats sont-ils liés à la mise en réseau d'hôte ou à la mise en réseau de ponts dans Docker?

— akaHuman

Avec de tels stddevs, ces mesures ne montrent aucune donnée représentableavg 200.5 min 0.6 max 263.2 stddev 73.85

— Sergey Zhukov