{"id":32331,"date":"2019-10-31T21:46:24","date_gmt":"2019-10-31T18:46:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya\/"},"modified":"2019-10-31T21:46:24","modified_gmt":"2019-10-31T18:46:24","slug":"steal-kto-kradyot-u-virtualok-protsessornoe-vremya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya","title":{"rendered":"Steal : qui vole du temps de processeur aux machines virtuelles","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Steal : qui vole du temps de processeur aux machines virtuelles\" src=\"\/wp-content\/uploads\/2019\/04\/23cac5d3cc3295dc6f1014e9fda36b89.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBonjour ! Je voudrais expliquer simplement la m\u00e9canique d'apparition du steal \u00e0 l'int\u00e9rieur des machines virtuelles et quelques artefacts non \u00e9vidents que nous avons pu d\u00e9couvrir lors de son \u00e9tude, dans laquelle j'ai d\u00fb m'immerger en tant que directeur technique de la plateforme cloud. <noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/\">Mail.ru Cloud Solutions<\/a><\/noindex>. La plateforme fonctionne sur KVM.<\/p>\n<p>Le temps de steal du CPU est le temps pendant lequel la machine virtuelle ne re\u00e7oit pas de ressources processeur pour son ex\u00e9cution. Ce temps n'est pris en compte que dans les syst\u00e8mes d'exploitation invit\u00e9s dans des environnements de virtualisation. Les raisons de la perte de ces ressources d\u00e9di\u00e9es, comme dans la vie, sont assez n\u00e9buleuses. Mais nous avons d\u00e9cid\u00e9 de nous pencher sur la question, et nous avons m\u00eame effectu\u00e9 une s\u00e9rie d'exp\u00e9riences. Ce n'est pas que nous savons tout sur le steal maintenant, mais nous allons partager quelques \u00e9l\u00e9ments int\u00e9ressants.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>1. Qu'est-ce que le steal<\/h2>\n<p>\nAinsi, le steal est une m\u00e9trique qui indique le manque de temps processeur pour les processus \u00e0 l'int\u00e9rieur de la machine virtuelle. Comme d\u00e9crit <noindex><a rel=\"nofollow\" href=\"https:\/\/git.kernel.org\/pub\/scm\/linux\/kernel\/git\/stable\/linux.git\/patch\/?id=c9aaa8957f203bd6df83b002fb40b98390bed078\">dans le patch du noyau KVM<\/a><\/noindex>, le steal est le temps pendant lequel l'hyperviseur ex\u00e9cute d'autres processus sur le syst\u00e8me d'exploitation h\u00f4te, bien qu'il ait mis le processus de la machine virtuelle en attente d'ex\u00e9cution. En d'autres termes, le steal se calcule comme la diff\u00e9rence entre le temps o\u00f9 le processus est pr\u00eat \u00e0 \u00eatre ex\u00e9cut\u00e9 et le temps o\u00f9 des ressources processeur lui sont effectivement attribu\u00e9es.<\/p>\n<p>La m\u00e9trique de steal est fournie \u00e0 la machine virtuelle par l'hyperviseur. Cependant, l'hyperviseur ne pr\u00e9cise pas quels autres processus il ex\u00e9cute, il se contente de dire : \u00ab tant que je suis occup\u00e9, je ne peux pas te donner de temps \u00bb. Sur KVM, le support du calcul du steal a \u00e9t\u00e9 ajout\u00e9 dans <noindex><a rel=\"nofollow\" href=\"https:\/\/lwn.net\/Articles\/449657\/\">les patches.<\/a><\/noindex>Il y a deux points cl\u00e9s ici : <\/p>\n<ul>\n<li>La machine virtuelle apprend le steal de l'hyperviseur. Ainsi, en termes de pertes, pour les processus sur la machine virtuelle elle-m\u00eame, c'est une mesure indirecte qui peut \u00eatre soumise \u00e0 diverses distorsions.\n<\/li>\n<li>L'hyperviseur ne partage pas avec la machine virtuelle des informations sur ce avec quoi il est occup\u00e9 \u2014 le principal point est qu'il ne lui accorde pas de temps. En raison de cela, la machine virtuelle elle-m\u00eame ne peut pas identifier les distorsions dans le chiffre du steal qui pourraient \u00eatre \u00e9valu\u00e9es en fonction de la nature des processus concurrents.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>2. Qu'est-ce qui influence le steal<\/h2>\n<p><\/p>\n<h3>2.1. Calcul du steal<\/h3>\n<p>\nEn fait, le steal est calcul\u00e9 \u00e0 peu pr\u00e8s de la m\u00eame mani\u00e8re que le temps d'utilisation normal du processeur. Il n'y a pas beaucoup d'information sur la fa\u00e7on dont l'utilisation est calcul\u00e9e. Peut-\u00eatre parce que la plupart des gens consid\u00e8rent cette question comme \u00e9vidente. Mais il y a aussi des pi\u00e8ges. Pour se familiariser avec ce processus, vous pouvez lire <noindex><a rel=\"nofollow\" href=\"http:\/\/www.brendangregg.com\/blog\/2017-05-09\/cpu-utilization-is-wrong.html\">l'article de Brendann Gregg<\/a><\/noindex>: vous apprendrez beaucoup de subtilit\u00e9s lors du calcul de l'utilisation et des situations o\u00f9 ce calcul peut \u00eatre erron\u00e9 pour les raisons suivantes :<\/p>\n<ul>\n<li>Surchauffe du processeur, entra\u00eenant des cycles manqu\u00e9s.\n<\/li>\n<li>Activation\/d\u00e9sactivation du turbo boost, modifiant ainsi la fr\u00e9quence d'horloge du processeur.\n<\/li>\n<li>Changement de la dur\u00e9e du quantum de temps, se produisant lors de l'utilisation de technologies d'\u00e9conomie d'\u00e9nergie pour le processeur, telles que SpeedStep.\n<\/li>\n<li>Probl\u00e8me du calcul moyen : estimer l'utilisation \u00e0 80 % durant une minute peut masquer un pic ponctuel \u00e0 100 %.\n<\/li>\n<li>Le verrouillage cyclique (spin lock) conduit \u00e0 ce que le processeur soit utilis\u00e9, mais le processus utilisateur ne voit pas d'avancement dans son ex\u00e9cution. En cons\u00e9quence, le taux d'utilisation du processeur par le processus sera de 100 %, alors que le temps processeur physique ne sera pas consomm\u00e9.\n<\/li>\n<\/ul>\n<p>\nJe n'ai pas trouv\u00e9 d'articles d\u00e9crivant un tel calcul pour le steal (si vous en connaissez, partagez-le en commentaires). Mais, d'apr\u00e8s les sources, le m\u00e9canisme de calcul est le m\u00eame que pour l'utilisation. Un autre compteur est juste ajout\u00e9 dans le noyau, sp\u00e9cifiquement pour le processus KVM (processus de machine virtuelle), qui compte la dur\u00e9e pendant laquelle le processus KVM est rest\u00e9 en attente de temps processeur. Le compteur obtient des informations sur le processeur \u00e0 partir de ses sp\u00e9cifications et v\u00e9rifie si tous ses ticks ont \u00e9t\u00e9 utilis\u00e9s par le processus de la machine virtuelle. Si oui, nous consid\u00e9rons que le processeur s'occupait uniquement du processus de la machine virtuelle. Sinon, nous informons qu'il \u00e9tait occup\u00e9 par autre chose, et du coup, du steal appara\u00eet. <\/p>\n<p>Le processus de calcul du steal est soumis aux m\u00eames probl\u00e8mes que le calcul normal de l'utilisation. Ce n'est pas \u00e0 dire que ces probl\u00e8mes apparaissent souvent, mais ils semblent d\u00e9courageants.<\/p>\n<h3>2.2. Types de virtualisation sur KVM<\/h3>\n<p>\nEn g\u00e9n\u00e9ral, il existe trois types de virtualisation, tous pris en charge par KVM. Le type de virtualisation peut affecter le m\u00e9canisme d'apparition du steal.<\/p>\n<p><b>Translating<\/b>. Dans ce cas, le fonctionnement du syst\u00e8me d'exploitation de la machine virtuelle avec les dispositifs physiques de l'hyperviseur se passe comme suit :<\/p>\n<ol>\n<li>Le syst\u00e8me d'exploitation invit\u00e9 envoie une commande \u00e0 son dispositif invit\u00e9.\n<\/li>\n<li>Le pilote du dispositif invit\u00e9 re\u00e7oit la commande, pr\u00e9pare une requ\u00eate pour le BIOS du dispositif et l'envoie \u00e0 l'hyperviseur.\n<\/li>\n<li>Le processus de l'hyperviseur traduit une commande en une commande pour l'appareil physique, la rendant ainsi, entre autres, plus s\u00e9curis\u00e9e.\n<\/li>\n<li>Le pilote de l'appareil physique re\u00e7oit la commande modifi\u00e9e et l'envoie d\u00e9j\u00e0 \u00e0 l'appareil physique lui-m\u00eame.\n<\/li>\n<li>Les r\u00e9sultats de l'ex\u00e9cution des commandes reviennent par le m\u00eame chemin. \n<\/li>\n<\/ol>\n<p>\nL'avantage de la traduction est qu'elle permet d'\u00e9muler n'importe quel appareil et ne n\u00e9cessite pas de pr\u00e9paration sp\u00e9ciale du noyau du syst\u00e8me d'exploitation. Mais cela a un co\u00fbt, principalement en termes de performances. <\/p>\n<p><b>Virtualisation mat\u00e9rielle<\/b>. Dans ce cas, l'appareil comprend au niveau mat\u00e9riel les commandes du syst\u00e8me d'exploitation. C'est la m\u00e9thode la plus rapide et la plus efficace. Mais, malheureusement, elle n'est pas prise en charge par tous les appareils physiques, hyperviseurs et syst\u00e8mes d'exploitation invit\u00e9s. Actuellement, les principaux dispositifs qui prennent en charge la virtualisation mat\u00e9rielle sont les processeurs.<\/p>\n<p><b>Paravirtualisation<\/b>. C'est la variante de virtualisation la plus courante sur KVM et le mode de virtualisation le plus r\u00e9pandu pour les syst\u00e8mes d'exploitation invit\u00e9s. Sa particularit\u00e9 est que l'interaction avec certaines sous-syst\u00e8mes de l'hyperviseur (par exemple, le r\u00e9seau ou la pile de disques) ou l'allocation de pages m\u00e9moire se fait via l'API de l'hyperviseur, sans traduction des commandes de bas niveau. Le inconv\u00e9nient de cette m\u00e9thode de virtualisation est la n\u00e9cessit\u00e9 de modifier le noyau du syst\u00e8me d'exploitation invit\u00e9, afin qu'il puisse interagir avec l'hyperviseur \u00e0 travers cette API. Mais cela est g\u00e9n\u00e9ralement r\u00e9solu par l'installation de pilotes sp\u00e9ciaux sur le syst\u00e8me d'exploitation invit\u00e9. Dans KVM, cette API s'appelle <noindex><a rel=\"nofollow\" href=\"https:\/\/www.ibm.com\/developerworks\/library\/l-virtio\/index.html\">API virtio<\/a><\/noindex>.<\/p>\n<p>En paravirtualisation, par rapport \u00e0 la traduction, le chemin vers l'appareil physique est consid\u00e9rablement raccourci gr\u00e2ce \u00e0 l'envoi de commandes directement de la machine virtuelle au processus de l'hyperviseur sur l'h\u00f4te. Cela permet d'acc\u00e9l\u00e9rer l'ex\u00e9cution de toutes les instructions \u00e0 l'int\u00e9rieur de la machine virtuelle. Dans KVM, cela est g\u00e9r\u00e9 par l'API virtio, qui ne fonctionne que pour certains dispositifs, tels que l'adaptateur r\u00e9seau ou le disque. C'est pourquoi des pilotes virtio sont install\u00e9s \u00e0 l'int\u00e9rieur des machines virtuelles. <\/p>\n<p>La contrepartie de cette acc\u00e9l\u00e9ration est que tous les processus ex\u00e9cut\u00e9s \u00e0 l'int\u00e9rieur de la machine virtuelle ne restent pas \u00e0 l'int\u00e9rieur. Cela cr\u00e9e certains effets secondaires qui peuvent entra\u00eener des probl\u00e8mes de contournement. Je recommande de commencer l'\u00e9tude approfondie de cette question par <noindex><a rel=\"nofollow\" href=\"https:\/\/lwn.net\/Articles\/239238\/\">Une API pour l'I\/O virtuel : virtio<\/a><\/noindex>.<\/p>\n<h3>2.3. La planification \u00ab \u00e9quitable \u00bb<\/h3>\n<p>\nLa machine virtuelle sur l'hyperviseur est, en fait, un processus ordinaire qui suit les lois de la planification (allocation des ressources entre les processus) dans le noyau Linux, c'est pourquoi nous allons l'examiner plus en d\u00e9tail. <\/p>\n<p>Linux utilise ce qu'on appelle le CFS, Completely Fair Scheduler, devenu le gestionnaire par d\u00e9faut depuis le noyau 2.6.23. Pour comprendre cet algorithme, vous pouvez lire l'architecture du noyau Linux ou les sources. L'id\u00e9e principale du CFS est d'allouer le temps processeur entre les processus en fonction de la dur\u00e9e de leur ex\u00e9cution. Plus un processus n\u00e9cessite de temps processeur, moins de ce temps il re\u00e7oit. Cela garantit une ex\u00e9cution \u00ab \u00e9quitable \u00bb de tous les processus \u2014 pour qu'un processus ne monopolise pas constamment tous les processeurs, et que les autres processus puissent \u00e9galement s'ex\u00e9cuter. <\/p>\n<p>Parfois, cette approche conduit \u00e0 des artefacts int\u00e9ressants. Les anciens utilisateurs de Linux se souviennent s\u00fbrement du gel d'un \u00e9diteur de texte ordinaire sur le bureau lors du lancement d'applications gourmandes en ressources comme un compilateur. Cela se produisait parce que les t\u00e2ches peu gourmandes des applications de bureau rivalisaient avec des t\u00e2ches consommant activement des ressources, telles que le compilateur. Le CFS consid\u00e8re cela comme injuste, c'est pourquoi il arr\u00eate p\u00e9riodiquement l'\u00e9diteur de texte et donne au processeur le temps de traiter les t\u00e2ches du compilateur. Cela a \u00e9t\u00e9 corrig\u00e9 gr\u00e2ce au m\u00e9canisme <noindex><a rel=\"nofollow\" href=\"https:\/\/marc.info\/?l=linux-kernel&amp;m=128978361700898\">sched_autogroup<\/a><\/noindex>, mais de nombreuses autres sp\u00e9cificit\u00e9s de l'allocation du temps processeur entre les t\u00e2ches subsistent. En r\u00e9alit\u00e9, il ne s'agit pas de l'\u00e9chec du CFS, mais d'une tentative d'attirer l'attention sur le fait que l'allocation \u00ab \u00e9quitable \u00bb du temps processeur n'est pas une t\u00e2che triviale.<\/p>\n<p>Un autre point important dans le planificateur est la pr\u00e9emption. C'est n\u00e9cessaire pour \u00e9vincer un processus gourmand du processeur et permettre \u00e0 d'autres de travailler. Le processus d'\u00e9viction s'appelle le changement de contexte, c'est-\u00e0-dire le basculement du contexte du processeur. \u00c0 ce moment-l\u00e0, tout le contexte de la t\u00e2che est sauvegard\u00e9 : l'\u00e9tat de la pile, les registres, etc., apr\u00e8s quoi le processus est mis en attente, et un autre prend sa place. C'est une op\u00e9ration co\u00fbteuse pour le syst\u00e8me d'exploitation, et elle est rarement utilis\u00e9e, mais en soi, il n'y a rien de mauvais l\u00e0-dedans. Un changement de contexte fr\u00e9quent peut indiquer un probl\u00e8me dans le syst\u00e8me d'exploitation, mais g\u00e9n\u00e9ralement, il se d\u00e9roule en continu et n'indique rien de particulier.<\/p>\n<p>Une telle longue explication est n\u00e9cessaire pour illustrer un fait : plus un processus essaie de consommer des ressources processeur dans un planificateur Linux \u00e9quitable, plus il sera rapidement arr\u00eat\u00e9 afin que d'autres processus puissent \u00e9galement travailler. Que ce soit juste ou non est une question complexe, qui se r\u00e9sout diff\u00e9remment selon les charges. Jusqu'\u00e0 r\u00e9cemment, dans Windows, le planificateur \u00e9tait orient\u00e9 vers le traitement prioritaire des applications de bureau, ce qui pouvait entra\u00eener des blocages pour les processus en arri\u00e8re-plan. Dans Sun Solaris, il y avait cinq classes diff\u00e9rentes de planificateurs. Lorsque la virtualisation a \u00e9t\u00e9 lanc\u00e9e, une sixi\u00e8me a \u00e9t\u00e9 ajout\u00e9e. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.opennet.ru\/man.shtml?topic=FSS&amp;category=7&amp;russian=4\">Planificateur de partage \u00e9quitable<\/a><\/noindex>, car les cinq pr\u00e9c\u00e9dents fonctionnaient de mani\u00e8re inad\u00e9quate avec la virtualisation des Zones Solaris. Je recommande de commencer par une \u00e9tude d\u00e9taill\u00e9e de ce sujet avec des livres comme <noindex><a rel=\"nofollow\" href=\"https:\/\/www.amazon.com\/Solaris-Internals-OpenSolaris-Kernel-Architecture\/dp\/0131482092\/\">Solaris Internals: Architecture du noyau Solaris 10 et OpenSolaris<\/a><\/noindex> ou <noindex><a rel=\"nofollow\" href=\"https:\/\/www.amazon.com\/Understanding-Linux-Kernel-Third-Daniel\/dp\/0596005652\/\">Understanding the Linux Kernel<\/a><\/noindex>.<\/p>\n<h3>2.4. Comment surveiller le steal ?<\/h3>\n<p>\nSurveiller le steal \u00e0 l'int\u00e9rieur d'une machine virtuelle, comme toute autre m\u00e9trique processeur, est simple : on peut utiliser n'importe quel outil de collecte de m\u00e9triques processeur. L'essentiel est que la machine virtuelle soit sur Linux. Windows, pour une raison inconnue, ne fournit pas cette information \u00e0 ses utilisateurs. \ud83d\ude41<\/p>\n<p><img decoding=\"async\" alt=\"Steal : qui vole du temps de processeur aux machines virtuelles\" src=\"\/wp-content\/uploads\/2019\/04\/3c7cd04f73fd6a74b86af81382090b69.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sortie de la commande top : d\u00e9tails de la charge processeur, dans la derni\u00e8re colonne \u00e0 droite \u2014 steal<\/i><\/p>\n<p>La difficult\u00e9 survient lors de la tentative d'obtenir ces informations depuis l'hyperviseur. On peut essayer de pr\u00e9voir le steal sur la machine h\u00f4te, par exemple, \u00e0 partir de la moyenne de charge (LA) \u2014 une valeur moyenne du nombre de processus en attente dans la file d'attente d'ex\u00e9cution. La m\u00e9thode de calcul de ce param\u00e8tre est complexe, mais en gros, si la LA normalis\u00e9e par le nombre de threads du processeur est sup\u00e9rieure \u00e0 1, cela indique que le serveur sous Linux est quelque peu surcharg\u00e9. <\/p>\n<p>Que attendent donc tous ces processus ? La r\u00e9ponse \u00e9vidente est le processeur. Mais cette r\u00e9ponse n'est pas tout \u00e0 fait correcte, car parfois le processeur est libre et la LA est \u00e9lev\u00e9e. Rappelez-vous, <noindex><a rel=\"nofollow\" href=\"https:\/\/serverfault.com\/questions\/911976\/redhat-nfs-cluster-high-load-average-suddenly\">comment le NFS tombe en panne et comment la LA augmente dans ce cas.<\/a><\/noindex>. Il en va de m\u00eame pour le disque et d'autres p\u00e9riph\u00e9riques d'entr\u00e9e\/sortie. En r\u00e9alit\u00e9, les processus peuvent attendre la fin de tout type de verrouillage, qu'il soit physique, li\u00e9 \u00e0 un p\u00e9riph\u00e9rique d'entr\u00e9e\/sortie, ou logique, comme un mutex. Cela inclut \u00e9galement les verrouillages au niveau mat\u00e9riel (comme la r\u00e9ponse du disque), ou logique (les soi-disant primitives de verrouillage, qui englobent de nombreuses entit\u00e9s, mutex adaptifs et spin, s\u00e9maphores, variables de condition, verrouillages rw, verrouillages ipc\u2026)<\/p>\n<p>Une autre particularit\u00e9 de la LA est qu'elle est calcul\u00e9e comme une moyenne \u00e0 travers le syst\u00e8me d'exploitation. Par exemple, 100 processus se disputent un fichier, et l\u00e0, LA=50. Une valeur aussi \u00e9lev\u00e9e semble indiquer que l'OS ne va pas bien. Mais pour certains codes mal \u00e9crits, cela peut \u00eatre un \u00e9tat normal, o\u00f9 seul ce code est en difficult\u00e9, tandis que d'autres processus du syst\u00e8me d'exploitation ne souffrent pas. <\/p>\n<p>\u00c0 cause de cette moyenne (de pas moins d'une minute), d\u00e9finir quoi que ce soit sur la base de l'indicateur LA est une t\u00e2che difficile, avec des r\u00e9sultats tr\u00e8s incertains dans des cas pr\u00e9cis. Si vous essayez de comprendre, vous d\u00e9couvrirez que les articles sur Wikip\u00e9dia et d'autres ressources disponibles ne d\u00e9crivent que les cas les plus simples, sans expliquer en profondeur le processus. Tous ceux qui s'y int\u00e9ressent, je les renvoie encore une fois, <noindex><a rel=\"nofollow\" href=\"http:\/\/www.brendangregg.com\/blog\/2017-08-08\/linux-load-averages.html\">ici, vers Brendann Gregg<\/a><\/noindex> \u00a0\u2014 par le biais des liens. Pour ceux qui pr\u00e9f\u00e8rent le fran\u00e7ais \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/335326\/\">la traduction de son article populaire sur la LA<\/a><\/noindex>.<\/p>\n<h2>3. Effets sp\u00e9ciaux<\/h2>\n<p>\nNous allons maintenant nous concentrer sur les principaux cas de steal que nous avons rencontr\u00e9s. Je vais expliquer comment ils d\u00e9coulent de tout ce qui a \u00e9t\u00e9 dit pr\u00e9c\u00e9demment et comment ils se rapportent aux indicateurs sur l'hyperviseur.<\/p>\n<p><b>Reutilisation<\/b>. C'est le cas le plus simple et le plus fr\u00e9quent : l'hyperviseur est surutilis\u00e9. En effet, de nombreuses machines virtuelles sont en cours d'ex\u00e9cution, une forte consommation de processeurs \u00e0 l'int\u00e9rieur d'elles, une grande concurrence, et une utilisation selon la LA sup\u00e9rieure \u00e0 1 (normalis\u00e9e en fonction des threads de processeur). \u00c0 l'int\u00e9rieur de toutes les machines virtuelles, tout est au ralentissement. Le steal transmis par l'hyperviseur augmente \u00e9galement, il faut redistribuer la charge ou \u00e9teindre quelqu'un. En somme, tout cela est logique et compr\u00e9hensible.<\/p>\n<p><b>Paravirtualisation contre instances isol\u00e9es<\/b>. Sur l'hyperviseur, il n'y a qu'une seule machine virtuelle qui consomme une petite partie de ses ressources, mais qui impose une forte charge en entr\u00e9e\/sortie, par exemple, sur le disque. Et d'une mani\u00e8re ou d'une autre, un l\u00e9ger steal appara\u00eet dans celle-ci, jusqu'\u00e0 10 % (comme le montrent plusieurs exp\u00e9riences men\u00e9es).<\/p>\n<p>C'est un cas int\u00e9ressant. Le steal appara\u00eet ici pr\u00e9cis\u00e9ment \u00e0 cause des blocages au niveau des pilotes paravirtualis\u00e9s. \u00c0 l'int\u00e9rieur de la machine virtuelle, une interruption est cr\u00e9\u00e9e, est trait\u00e9e par le pilote et se dirige vers l'hyperviseur. En raison du traitement de l'interruption sur l'hyperviseur, cela semble \u00eatre une requ\u00eate envoy\u00e9e pour la machine virtuelle, qui est pr\u00eate \u00e0 s'ex\u00e9cuter et attend le processeur, mais elle ne re\u00e7oit pas de temps processeur. La machine virtuelle pense que ce temps a \u00e9t\u00e9 vol\u00e9. <\/p>\n<p>Cela se produit au moment de l'envoi du tampon, qui quitte l'espace noyau de l'hyperviseur, et nous commen\u00e7ons \u00e0 l'attendre. Pourtant, du point de vue de la machine virtuelle, il devrait revenir imm\u00e9diatement. Par cons\u00e9quent, selon l'algorithme de calcul du steal, ce temps est consid\u00e9r\u00e9 comme vol\u00e9. Il est probable que dans cette situation, d'autres m\u00e9canismes puissent aussi \u00eatre \u00e0 l'\u0153uvre (par exemple, le traitement d'autres appels syst\u00e8mes), mais ils ne devraient pas diff\u00e9rer beaucoup.<\/p>\n<p><b>Planificateur contre machines virtuelles \u00e0 forte charge<\/b>. Lorsque qu'une machine virtuelle subit plus de steal que d'autres, c'est justement li\u00e9 au planificateur. Plus le processus sollicite le processeur, plus le planificateur l'expulsera rapidement pour que les autres puissent \u00e9galement travailler. Si la machine virtuelle consomme peu de ressources, elle ne remarquera presque pas le steal : son processus \u00e9tait simplement en attente, il faut lui donner plus de temps. Si la machine virtuelle g\u00e9n\u00e8re une charge maximale sur tous ses c\u0153urs, elle est expuls\u00e9e plus souvent du processeur et on essaie de ne pas lui donner trop de temps. <\/p>\n<p>C'est encore pire lorsque des processus au sein de la machine virtuelle essaient d'acqu\u00e9rir plus de puissance processeur car ils ont du mal \u00e0 traiter les donn\u00e9es. Dans ce cas, le syst\u00e8me d'exploitation sur l'hyperviseur, gr\u00e2ce \u00e0 une optimisation juste, tendra \u00e0 accorder de moins en moins de temps processeur. Ce processus se d\u00e9roule de mani\u00e8re exponentielle et le steal grimpe en fl\u00e8che, bien que les autres machines virtuelles puissent \u00e0 peine le remarquer. Et plus il y a de c\u0153urs, plus la machine sous pression en souffre. En r\u00e9sum\u00e9, les machines virtuelles \u00e0 forte charge avec plusieurs c\u0153urs sont les plus touch\u00e9es.<\/p>\n<p><b>LA faible, mais il y a du steal<\/b>. Si le LA est d'environ 0,7 (c'est-\u00e0-dire que l'hyperviseur semble sous charg\u00e9), mais qu'il y a une observation de steal dans certaines machines virtuelles :<\/p>\n<ul>\n<li>La variante d\u00e9crite ci-dessus avec la paravirtualisation. Une machine virtuelle peut recevoir des m\u00e9triques indiquant un vol de temps CPU, m\u00eame si tout va bien du c\u00f4t\u00e9 de l'hyperviseur. D'apr\u00e8s nos exp\u00e9riences, ce type de vol ne d\u00e9passe pas 10 % et ne devrait pas avoir d'impact significatif sur les performances des applications \u00e0 l'int\u00e9rieur de la machine virtuelle.\n<\/li>\n<li>Le param\u00e8tre LA est mal consid\u00e9r\u00e9. Plus pr\u00e9cis\u00e9ment, \u00e0 chaque moment pr\u00e9cis, il est calcul\u00e9 correctement, mais lorsqu'il est moyenn\u00e9 sur une minute, il se retrouve sous-\u00e9valu\u00e9. Par exemple, si une machine virtuelle utilise tous ses processeurs exactement pendant une demi-minute sur un tiers de l'hyperviseur, le LA pour cette minute sur l'hyperviseur sera de 0,15 ; quatre machines virtuelles de ce type fonctionnant simultan\u00e9ment donneront 0,6. Cependant, le fait qu'il y ait eu un vol \u00e9norme proche de 25 % sur chaque machine pendant une demi-minute ne pourra pas \u00eatre r\u00e9cup\u00e9r\u00e9.\n<\/li>\n<li>Encore une fois, \u00e0 cause du planificateur, qui a d\u00e9cid\u00e9 que quelqu'un mangeait trop et qu'il devait attendre. Pendant ce temps, je vais changer de contexte, traiter les interruptions et m'occuper d'autres choses syst\u00e8me importantes. Au final, certaines machines virtuelles ne voient aucun probl\u00e8me, tandis que d'autres subissent une d\u00e9gradation s\u00e9rieuse des performances.\n<\/li>\n<\/ul>\n<p><\/p>\n<h2>4. Autres distorsions<\/h2>\n<p>\nIl existe encore un million de raisons de distorsion dans la r\u00e9partition \u00e9quitable du temps CPU sur une machine virtuelle. Par exemple, l'hyperthreading et NUMA compliquent les calculs. Ils rendent le choix de c\u0153ur pour l'ex\u00e9cution d'un processus encore plus confus, car le planificateur utilise des coefficients \u2014 des poids, qui compliquent encore le calcul lors du changement de contexte.<\/p>\n<p>Des distorsions peuvent \u00e9galement se produire \u00e0 cause de technologies comme le turbo boost ou, au contraire, le mode \u00e9conomie d'\u00e9nergie, qui peuvent artificiellement augmenter ou diminuer la fr\u00e9quence ou m\u00eame le quantum de temps sur le serveur lors du calcul de l'utilisation. L'activation du turbo boost r\u00e9duit les performances d'un thread processeur en raison de l'augmentation des performances d'un autre. \u00c0 ce moment, l'information sur la fr\u00e9quence actuelle du processeur n'est pas transmise \u00e0 la machine virtuelle, qui pense que son temps est vol\u00e9 (par exemple, elle a demand\u00e9 2 GHz, mais en re\u00e7oit deux fois moins). <\/p>\n<p>En g\u00e9n\u00e9ral, il peut y avoir de nombreuses raisons de distorsions. Dans un syst\u00e8me sp\u00e9cifique, vous pouvez d\u00e9celer d'autres \u00e9l\u00e9ments. Il vaut mieux commencer par les livres dont j'ai fourni les liens ci-dessus et par la collecte de statistiques \u00e0 partir de l'hyperviseur avec des outils comme perf, sysdig, systemtap, qui sont <noindex><a rel=\"nofollow\" href=\"https:\/\/jvns.ca\/blog\/2017\/07\/05\/linux-tracing-systems\/\">des dizaines<\/a><\/noindex>.<\/p>\n<h2>5. Conclusions<\/h2>\n<p><\/p>\n<ol>\n<li>Une certaine quantit\u00e9 de steal peut survenir en raison de la paravirtualisation, et cela peut \u00eatre consid\u00e9r\u00e9 comme normal. Sur internet, on mentionne que ce chiffre peut atteindre 5 \u00e0 10 %. Cela d\u00e9pend des applications \u00e0 l'int\u00e9rieur de la machine virtuelle et de la charge qu'elles imposent \u00e0 leurs dispositifs physiques. Il est important de pr\u00eater attention \u00e0 la mani\u00e8re dont les applications se comportent \u00e0 l'int\u00e9rieur des machines virtuelles.\n<\/li>\n<li>Le rapport entre la charge sur l'hyperviseur et le steal \u00e0 l'int\u00e9rieur de la machine virtuelle n'est pas toujours clairement corr\u00e9l\u00e9 ; les deux \u00e9valuations du steal peuvent \u00eatre erron\u00e9es dans des situations sp\u00e9cifiques lors de diff\u00e9rentes charges.\n<\/li>\n<li>Le planificateur n'est pas bienveillant envers les processus qui demandent beaucoup. Il essaie de donner moins \u00e0 ceux qui demandent plus. Les grandes machines virtuelles sont un mal.\n<\/li>\n<li>Un petit steal peut \u00eatre normal m\u00eame sans paravirtualisation (teneur compte de la charge \u00e0 l'int\u00e9rieur de la machine virtuelle, des caract\u00e9ristiques des charges voisines, de la r\u00e9partition des charges par threads et d'autres facteurs).\n<\/li>\n<li>Si vous souhaitez d\u00e9terminer le steal dans un syst\u00e8me sp\u00e9cifique, il faut examiner diff\u00e9rentes options, collecter des m\u00e9triques, les analyser soigneusement et r\u00e9fl\u00e9chir \u00e0 la mani\u00e8re de r\u00e9partir uniform\u00e9ment la charge. Des \u00e9carts peuvent se produire dans tous les cas, et ils doivent \u00eatre valid\u00e9s par des exp\u00e9riences ou en consultant le d\u00e9bogueur du noyau.\n<\/li>\n<\/ol>\n<p>Source : <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/449316\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442! \u0425\u043e\u0447\u0443 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u043f\u0440\u043e\u0441\u0442\u044b\u043c \u044f\u0437\u044b\u043a\u043e\u043c \u043e \u043c\u0435\u0445\u0430\u043d\u0438\u043a\u0435 \u0432\u043e\u0437\u043d\u0438\u043a\u043d\u043e\u0432\u0435\u043d\u0438\u044f steal \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0445 \u043c\u0430\u0448\u0438\u043d \u0438 \u043e \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u043d\u0435\u043e\u0447\u0435\u0432\u0438\u0434\u043d\u044b\u0445 \u0430\u0440\u0442\u0435\u0444\u0430\u043a\u0442\u0430\u0445, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043d\u0430\u043c \u0443\u0434\u0430\u043b\u043e\u0441\u044c \u0432\u044b\u044f\u0441\u043d\u0438\u0442\u044c \u043f\u0440\u0438 \u0435\u0433\u043e \u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u0438, \u0432 \u043a\u043e\u0442\u043e\u0440\u043e\u0435 \u043c\u043d\u0435 \u043f\u0440\u0438\u0448\u043b\u043e\u0441\u044c \u043f\u043e\u0433\u0440\u0443\u0437\u0438\u0442\u044c\u0441\u044f \u043a\u0430\u043a \u0442\u0435\u0445\u0434\u0438\u0440\u0443 \u043e\u0431\u043b\u0430\u0447\u043d\u043e\u0439 \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b Mail.ru Cloud Solutions. \u041f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u0430 \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u043d\u0430 KVM. CPU steal time \u2014 \u044d\u0442\u043e \u0432\u0440\u0435\u043c\u044f, \u0432 \u0442\u0435\u0447\u0435\u043d\u0438\u0435 \u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u0430\u044f \u043c\u0430\u0448\u0438\u043d\u0430 \u043d\u0435 \u043f\u043e\u043b\u0443\u0447\u0430\u0435\u0442 \u0440\u0435\u0441\u0443\u0440\u0441\u044b \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0440\u0430 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24147,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-32331","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442!\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Steal: \u043a\u0442\u043e \u043a\u0440\u0430\u0434\u0451\u0442 \u0443 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u043e\u043a \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0440\u043d\u043e\u0435 \u0432\u0440\u0435\u043c\u044f | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442!\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:46:24+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:46:24+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Steal : qui vole du temps processeur aux machines virtuelles | ProHoster","description":"Bonjour !","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Steal: \u043a\u0442\u043e \u043a\u0440\u0430\u0434\u0451\u0442 \u0443 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u043e\u043a \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u043e\u0440\u043d\u043e\u0435 \u0432\u0440\u0435\u043c\u044f | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442!","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/steal-kto-kradyot-u-virtualok-protsessornoe-vremya","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:46:24+00:00","article:modified_time":"2019-10-31T18:46:24+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"32331","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 10:21:22","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:00:23","updated":"2026-01-21 10:21:22","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/32331","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=32331"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/32331\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/24147"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=32331"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=32331"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=32331"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}