{"id":34335,"date":"2019-10-31T21:57:43","date_gmt":"2019-10-31T18:57:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu\/"},"modified":"2019-10-31T21:57:43","modified_gmt":"2019-10-31T18:57:43","slug":"analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu","title":{"rendered":"Analyse des performances des machines virtuelles dans VMware vSphere. Partie 1 : CPU","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Analyse des performances des machines virtuelles dans VMware vSphere. Partie 1 : CPU\" src=\"\/wp-content\/uploads\/2019\/05\/0c077a1754c2e32c1f339999ceacf03a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSi vous administrez une infrastructure virtuelle bas\u00e9e sur VMware vSphere (ou toute autre pile technologique), vous entendez probablement fr\u00e9quemment des plaintes des utilisateurs : \u00ab La machine virtuelle est lente ! \u00bb. Dans ce cycle d'articles, j'examinerai les m\u00e9triques de performances et expliquerai ce qui \u00ab ralentit \u00bb et pourquoi, ainsi que comment y rem\u00e9dier.<\/p>\n<p>Je vais consid\u00e9rer les aspects suivants des performances des machines virtuelles :<\/p>\n<ul>\n<li>CPU,<\/li>\n<li>RAM,<\/li>\n<li>DISQUE,<\/li>\n<li>R\u00e9seau.<\/li>\n<\/ul>\n<p>\nJe commencerai par le CPU.<\/p>\n<p>Pour analyser les performances, nous aurons besoin :<\/p>\n<ul>\n<li><b>VCenter Performance Counters<\/b> \u2013 compteurs de performance, dont les graphiques peuvent \u00eatre consult\u00e9s via le vSphere Client. Les informations sur ces compteurs sont disponibles dans toutes les versions du client (client \u00ab lourd \u00bb en C#, client web en Flex et client web en HTML5). Dans ces articles, nous utiliserons des captures d'\u00e9cran du client C#, simplement parce qu'elles rendent mieux en miniature :)<\/li>\n<li><b>ESXTOP<\/b> \u2013 un outil lanc\u00e9 depuis la ligne de commande d'ESXi. Il permet d'obtenir les valeurs des compteurs de performance en temps r\u00e9el ou d'exporter ces valeurs sur une p\u00e9riode d\u00e9termin\u00e9e dans un fichier .csv pour une analyse ult\u00e9rieure. Je vais expliquer cet outil plus en d\u00e9tail et fournir quelques liens utiles vers la documentation et des articles sur le sujet.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Un peu de th\u00e9orie<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Analyse des performances des machines virtuelles dans VMware vSphere. Partie 1 : CPU\" src=\"\/wp-content\/uploads\/2019\/05\/bc415aace7653c45850d26b7104483c9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDans ESXi, chaque vCPU (c\u0153ur de la machine virtuelle) est g\u00e9r\u00e9 par un processus distinct \u2013 world dans la terminologie VMware. Il existe \u00e9galement des processus de service, mais du point de vue de l'analyse de performance des VMs, ils sont moins int\u00e9ressants.<\/p>\n<p>Un processus dans ESXi peut se trouver dans l'un des quatre \u00e9tats :<\/p>\n<ul>\n<li><b>Ex\u00e9cution<\/b> \u2013 le processus effectue un travail utile.<\/li>\n<li><b>Attente<\/b> \u2013 le processus n'effectue aucun travail (inactif) ou attend une entr\u00e9e\/sortie.<\/li>\n<li><b>Stop<\/b> \u2013 un \u00e9tat qui se produit dans les machines virtuelles multic\u0153urs. Il se produit lorsque le planificateur CPU de l'hyperviseur (ESXi CPU Scheduler) ne peut pas programmer l'ex\u00e9cution simultan\u00e9e sur les c\u0153urs physiques du serveur de tous les c\u0153urs actifs de la machine virtuelle. Dans le monde physique, tous les c\u0153urs de processeur fonctionnent en parall\u00e8le, le syst\u00e8me d'exploitation invit\u00e9 \u00e0 l'int\u00e9rieur de la VM s'attend \u00e0 un comportement similaire, c'est pourquoi l'hyperviseur doit ralentir les c\u0153urs de la VM qui ont la possibilit\u00e9 de terminer leur cycle plus rapidement. Dans les versions modernes d'ESXi, le planificateur CPU utilise un m\u00e9canisme appel\u00e9 co-scheduling assoupli : l'hyperviseur consid\u00e8re l'\u00e9cart entre le c\u0153ur de la machine virtuelle le plus \u00ab rapide \u00bb et le plus \u00ab lent \u00bb (skew). Si cet \u00e9cart d\u00e9passe un certain seuil, le c\u0153ur \u00ab rapide \u00bb passe en \u00e9tat de costop. Si les c\u0153urs de la VM passent beaucoup de temps dans cet \u00e9tat, cela peut entra\u00eener des probl\u00e8mes de performance.<\/li>\n<li><b>Pr\u00eat<\/b> \u2013 un processus passe dans cet \u00e9tat lorsque l'hyperviseur n'a pas la possibilit\u00e9 d'allouer des ressources pour son ex\u00e9cution. Des valeurs \u00e9lev\u00e9es de ready peuvent provoquer des probl\u00e8mes de performance de la VM.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Principaux compteurs de performance CPU de la machine virtuelle<\/h3>\n<p>\n<b>Utilisation CPU, %.<\/b> Montre le pourcentage d'utilisation du CPU sur une p\u00e9riode donn\u00e9e.<\/p>\n<p><img decoding=\"async\" alt=\"Analyse des performances des machines virtuelles dans VMware vSphere. Partie 1 : CPU\" src=\"\/wp-content\/uploads\/2019\/05\/7a5da7dcd45329c3aae8e394c5d35a30.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Comment analyser ?<\/b> Si la VM utilise de mani\u00e8re stable le CPU \u00e0 90 % ou qu'il y a des pics allant jusqu'\u00e0 100 %, nous avons des probl\u00e8mes. Ces probl\u00e8mes peuvent se manifester non seulement par un fonctionnement \u00ab lent \u00bb de l'application \u00e0 l'int\u00e9rieur de la VM, mais aussi par l'inaccessibilit\u00e9 de la VM sur le r\u00e9seau. Si le syst\u00e8me de surveillance montre que la VM se d\u00e9connecte p\u00e9riodiquement, faites attention aux pics sur le graphique d'utilisation du CPU.<\/p>\n<p>Il existe une alarme standard qui montre la charge CPU de la machine virtuelle :<\/p>\n<p><img decoding=\"async\" alt=\"Analyse des performances des machines virtuelles dans VMware vSphere. Partie 1 : CPU\" src=\"\/wp-content\/uploads\/2019\/05\/9bfd9bb5b43b9b02e8bbfac307d6c9f9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Que faire ?<\/b> Si l'utilisation du CPU de la VM d\u00e9passe constamment, il peut \u00eatre judicieux d'augmenter le nombre de vCPU (malheureusement, ce n'est pas toujours efficace) ou de d\u00e9placer la VM sur un serveur avec des processeurs plus performants.<\/p>\n<h3>Utilisation du CPU en Mhz<\/h3>\n<p>\nDans les graphiques sur vCenter, l'utilisation en % ne peut \u00eatre consult\u00e9e que pour l'ensemble de la machine virtuelle, il n'y a pas de graphiques pour des c\u0153urs s\u00e9par\u00e9s (dans Esxtop, les valeurs en % par c\u0153ur existent). Pour chaque c\u0153ur, l'utilisation en MHz peut \u00eatre consult\u00e9e.<\/p>\n<p><b>Comment analyser ?<\/b> Il arrive qu'une application ne soit pas optimis\u00e9e pour une architecture multic\u0153ur : elle utilise \u00e0 100 % un seul c\u0153ur pendant que les autres restent inactifs. Par exemple, avec les param\u00e8tres par d\u00e9faut de sauvegarde, MS SQL d\u00e9marre le processus uniquement sur un c\u0153ur. En fin de compte, la sauvegarde est ralentie non pas par une lenteur des disques (c'est ce que l'utilisateur a initialement signal\u00e9), mais parce que le processeur est d\u00e9bord\u00e9. Le probl\u00e8me a \u00e9t\u00e9 r\u00e9solu en modifiant les param\u00e8tres : la sauvegarde a commenc\u00e9 \u00e0 s'ex\u00e9cuter en parall\u00e8le dans plusieurs fichiers (donc dans plusieurs processus).<\/p>\n<p><img decoding=\"async\" alt=\"Analyse des performances des machines virtuelles dans VMware vSphere. Partie 1 : CPU\" src=\"\/wp-content\/uploads\/2019\/05\/d1bce5fe5ef89a69c31a6a8f043d5d24.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Exemple de charge in\u00e9gale des c\u0153urs.<\/i><\/p>\n<p>Il peut \u00e9galement y avoir une situation (comme sur le graphique ci-dessus) o\u00f9 les c\u0153urs sont charg\u00e9s de mani\u00e8re in\u00e9gale et o\u00f9 certains d'entre eux pr\u00e9sentent des pics \u00e0 100 %. Tout comme lorsque seul un c\u0153ur est charg\u00e9, l'alarme concernant l'utilisation CPU ne se d\u00e9clenchera pas (elle est bas\u00e9e sur l'ensemble de la VM), mais des probl\u00e8mes de performance seront pr\u00e9sents.<\/p>\n<p><b>Que faire ? <\/b>Si le logiciel dans la machine virtuelle charge les c\u0153urs de mani\u00e8re in\u00e9gale (n'utilisant qu'un seul c\u0153ur ou une partie des c\u0153urs), il n'est pas utile d'augmenter leur nombre. Dans ce cas, il est pr\u00e9f\u00e9rable de d\u00e9placer la VM vers un serveur avec des processeurs plus performants.<\/p>\n<p>Vous pouvez \u00e9galement essayer de v\u00e9rifier les param\u00e8tres de consommation d'\u00e9nergie dans le BIOS du serveur. De nombreux administrateurs activent dans le BIOS le mode Haute Performance et d\u00e9sactivent ainsi les technologies d'\u00e9conomie d'\u00e9nergie C-states et P-states. Les processeurs Intel modernes utilisent la technologie Turbo Boost, qui augmente la fr\u00e9quence des c\u0153urs individuels du processeur au d\u00e9triment d'autres c\u0153urs. Mais elle ne fonctionne que si les technologies d'\u00e9conomie d'\u00e9nergie sont activ\u00e9es. Si nous les d\u00e9sactivons, le processeur ne peut pas r\u00e9duire la consommation \u00e9nerg\u00e9tique des c\u0153urs qui ne sont pas sollicit\u00e9s. <\/p>\n<p>VMware recommande de ne pas d\u00e9sactiver les technologies d'\u00e9conomie d'\u00e9nergie sur les serveurs, mais de choisir des modes qui laissent le contr\u00f4le de la consommation d'\u00e9nergie au hyperviseur. De plus, dans les param\u00e8tres de consommation d'\u00e9nergie de l'hyperviseur, il faut s\u00e9lectionner Haute Performance. <\/p>\n<p>Si vous avez dans votre infrastructure des VM (ou des c\u0153urs de VM) qui n\u00e9cessitent une fr\u00e9quence CPU \u00e9lev\u00e9e, un r\u00e9glage correct de la consommation d'\u00e9nergie peut am\u00e9liorer consid\u00e9rablement leurs performances.<\/p>\n<p><img decoding=\"async\" alt=\"Analyse des performances des machines virtuelles dans VMware vSphere. Partie 1 : CPU\" src=\"\/wp-content\/uploads\/2019\/05\/59aec2b77fa87e413d90371a11388629.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>CPU Ready (Pr\u00eat du CPU) <\/h3>\n<p>\nSi le noyau de la machine virtuelle (vCPU) est en \u00e9tat Ready, il n'effectue aucun travail utile. Cet \u00e9tat survient lorsque l'hyperviseur ne trouve pas de noyau physique libre sur lequel il peut assigner le processus vCPU de la machine virtuelle.<\/p>\n<p><b>Comment analyser ?<\/b> En g\u00e9n\u00e9ral, si les noyaux de la machine virtuelle sont en \u00e9tat Ready plus de 10 % du temps, vous remarquerez des probl\u00e8mes de performance. En d'autres termes, plus de 10 % du temps, la machine virtuelle attend la disponibilit\u00e9 des ressources physiques.<\/p>\n<p>Dans vCenter, vous pouvez voir deux compteurs li\u00e9s \u00e0 CPU Ready :<\/p>\n<ul>\n<li>Readiness,<\/li>\n<li>Ready.<\/li>\n<\/ul>\n<p>\nLes valeurs des deux compteurs peuvent \u00eatre consult\u00e9es \u00e0 la fois pour l'ensemble de la machine virtuelle et pour des noyaux individuels.<br \/>\nReadiness affiche la valeur imm\u00e9diatement en pourcentage, mais uniquement en temps r\u00e9el (donn\u00e9es de la derni\u00e8re heure, intervalle de mesure de 20 secondes). Ce compteur est pr\u00e9f\u00e9rable \u00e0 utiliser uniquement pour d\u00e9tecter des probl\u00e8mes \u00ab \u00e0 chaud \u00bb.<\/p>\n<p>Les valeurs du compteur Ready peuvent \u00e9galement \u00eatre consult\u00e9es dans une perspective historique. Cela est utile pour \u00e9tablir des mod\u00e8les et pour une analyse plus approfondie du probl\u00e8me. Par exemple, si une machine virtuelle commence \u00e0 avoir des probl\u00e8mes de performance \u00e0 un moment donn\u00e9, il est possible de comparer les intervalles de valeur \u00e9lev\u00e9e de CPU Ready avec la charge g\u00e9n\u00e9rale du serveur sur lequel cette machine virtuelle fonctionne, et de prendre des mesures pour r\u00e9duire la charge (si DRS n'a pas r\u00e9ussi).<\/p>\n<p>Ready, contrairement \u00e0 Readiness, n'est pas montr\u00e9 en pourcentage, mais en millisecondes. C'est un compteur de type Somme, ce qui signifie qu'il indique combien de temps, pendant la p\u00e9riode de mesure, le noyau de la machine virtuelle a \u00e9t\u00e9 en \u00e9tat Ready. Cette valeur peut \u00eatre convertie en pourcentage par une formule simple :<\/p>\n<p>(valeur de sommation CPU ready \/ (intervalle de mise \u00e0 jour par d\u00e9faut du graphique en secondes * 1000)) * 100 = CPU ready %<\/p>\n<p>Par exemple, pour la machine virtuelle sur le graphique ci-dessous, la valeur maximale de Ready pour l'ensemble de la machine virtuelle sera la suivante : <\/p>\n<p><img decoding=\"async\" alt=\"Analyse des performances des machines virtuelles dans VMware vSphere. Partie 1 : CPU\" src=\"\/wp-content\/uploads\/2019\/05\/3e2df8bca55b572502d88b838cbc306e.jpg\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p><img decoding=\"async\" alt=\"Analyse des performances des machines virtuelles dans VMware vSphere. Partie 1 : CPU\" src=\"\/wp-content\/uploads\/2019\/05\/f0371c9cd655c1e4785e90debde61dc8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLorsque vous calculez la valeur de Ready en pourcentage, il est important de pr\u00eater attention \u00e0 deux points :<\/p>\n<ul>\n<li>La valeur Ready pour l'ensemble de la machine virtuelle est la somme de Ready pour les noyaux.<\/li>\n<li>L'intervalle de mesure. Pour Real-time, c'est 20 secondes, et, par exemple, sur les graphiques quotidiens, c'est 300 secondes.<\/li>\n<\/ul>\n<p>\nLors d'un d\u00e9pannage actif, ces simples points peuvent facilement \u00eatre n\u00e9glig\u00e9s et vous pourriez perdre un temps pr\u00e9cieux \u00e0 r\u00e9soudre des probl\u00e8mes inexistants. <\/p>\n<p>Nous calculons le Ready en fonction des donn\u00e9es du graphique ci-dessous. (324474\/(20*1000))*100 = 1622% pour l'ensemble de la VM. Si l'on regarde par c\u0153urs, ce n'est pas si inqui\u00e9tant : 1622\/64 = 25% par c\u0153ur. Dans ce cas, il est assez facile de d\u00e9tecter le probl\u00e8me : la valeur Ready est irr\u00e9aliste. Mais s'il s'agit de 10 \u00e0 20% pour toute la VM avec plusieurs c\u0153urs, alors pour chaque c\u0153ur, la valeur peut \u00eatre dans les limites normales.<\/p>\n<p><img decoding=\"async\" alt=\"Analyse des performances des machines virtuelles dans VMware vSphere. Partie 1 : CPU\" src=\"\/wp-content\/uploads\/2019\/05\/703ab2b1f1fab8bda10aad781c2cef78.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Que faire ? <\/b>Une valeur \u00e9lev\u00e9e de Ready indique que le serveur manque de ressources processeur pour fonctionner normalement avec les machines virtuelles. Dans cette situation, il ne reste plus qu'\u00e0 r\u00e9duire la surallocation CPU (vCPU:pCPU). Il est \u00e9vident que cela peut \u00eatre r\u00e9alis\u00e9 en diminuant les sp\u00e9cifications des VM existantes ou en migrant certaines VM vers d'autres serveurs.<\/p>\n<h3>Co-stop<\/h3>\n<p>\n<b>Comment analyser ?<\/b> Ce compteur a \u00e9galement le type Somme et se traduit en pourcentages de la m\u00eame mani\u00e8re que Ready :<\/p>\n<p>(valeur de somme de co-stop CPU \/ (intervalle de mise \u00e0 jour par d\u00e9faut du graphique en secondes * 1000)) * 100 = % de co-stop CPU<\/p>\n<p>Il faut \u00e9galement faire attention au nombre de c\u0153urs sur la VM et \u00e0 l'intervalle de mesure.<br \/>\nEn \u00e9tat de co-stop, le c\u0153ur n'ex\u00e9cute pas de travail utile. Avec un dimensionnement correct de la VM et une charge normale sur le serveur, le compteur de co-stop doit \u00eatre proche de z\u00e9ro.<\/p>\n<p><img decoding=\"async\" alt=\"Analyse des performances des machines virtuelles dans VMware vSphere. Partie 1 : CPU\" src=\"\/wp-content\/uploads\/2019\/05\/e226afbf91155c2d5d3fdc4571e7383a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Dans ce cas, la charge est clairement anormale :)<\/i><\/p>\n<p><b>Que faire ?<\/b> Si plusieurs VM avec un grand nombre de c\u0153urs fonctionnent sur un m\u00eame hyperviseur et qu'il y a une surallocation CPU, le compteur de co-stop peut augmenter, ce qui entra\u00eenera des probl\u00e8mes de performance pour ces VM. <\/p>\n<p>Le co-stop augmentera \u00e9galement si les c\u0153urs actifs d'une VM utilisent des threads sur un m\u00eame c\u0153ur physique du serveur avec hyper-threading activ\u00e9. Cela peut se produire, par exemple, si la VM a plus de c\u0153urs que ceux physiquement disponibles sur le serveur o\u00f9 elle fonctionne, ou si pour la VM l'option 'preferHT' est activ\u00e9e. On peut lire \u00e0 propos de ce r\u00e9glage. <noindex><a rel=\"nofollow\" href=\"https:\/\/blogs.vmware.com\/vsphere\/2014\/03\/perferht-use-2.html\">ici<\/a><\/noindex>. <\/p>\n<p>Pour \u00e9viter les probl\u00e8mes de performance de la VM dus \u00e0 un co-stop \u00e9lev\u00e9, choisissez la taille de la VM conform\u00e9ment aux recommandations du fournisseur de logiciels qui fonctionne sur cette VM et aux capacit\u00e9s du serveur physique sur lequel la VM est ex\u00e9cut\u00e9e. <\/p>\n<p>N'ajoutez pas de c\u0153urs en surplus, cela peut provoquer des probl\u00e8mes de performance non seulement pour la VM elle-m\u00eame, mais aussi pour ses voisines sur le serveur.<\/p>\n<h3>D'autres m\u00e9triques utiles du CPU<\/h3>\n<p>\n<b>Ex\u00e9cution<\/b> \u2013 combien de temps (ms) pendant la p\u00e9riode de mesure le vCPU a \u00e9t\u00e9 en \u00e9tat de RUN, c'est-\u00e0-dire qu'il a effectivement effectu\u00e9 un travail utile.<\/p>\n<p><b>Idle<\/b> \u2013 combien de temps (ms) au cours de la p\u00e9riode de mesure le vCPU a \u00e9t\u00e9 inactif. Des valeurs \u00e9lev\u00e9es d'Idle ne posent pas de probl\u00e8me, cela signifie simplement que le vCPU n'avait \u00ab rien \u00e0 faire \u00bb.<\/p>\n<p><b>Attente<\/b> \u2013 combien de temps (ms) au cours de la p\u00e9riode de mesure le vCPU a \u00e9t\u00e9 en \u00e9tat d'attente. Comme ce compteur inclut l'IDLE, des valeurs \u00e9lev\u00e9es de Wait ne signent pas non plus un probl\u00e8me. Cependant, si l'IDLE est bas avec un Wait \u00e9lev\u00e9, cela signifie que la VM attendait la fin des op\u00e9rations d'entr\u00e9e\/sortie. Cela peut indiquer un probl\u00e8me de performance du disque dur ou de certains appareils virtuels de la VM.<\/p>\n<p><b>Max limit\u00e9<\/b> \u2013 combien de temps (ms) au cours de la p\u00e9riode de mesure le vCPU a \u00e9t\u00e9 en \u00e9tat Ready en raison d'une limite de ressources d\u00e9finie. Si la performance est inexplicablement basse, il est utile de v\u00e9rifier la valeur de ce compteur et la limite CPU dans les param\u00e8tres de la VM. Il se peut que des limites soient effectivement appliqu\u00e9es \u00e0 la VM sans que vous le sachiez. Par exemple, cela se produit lorsque la VM a \u00e9t\u00e9 clon\u00e9e \u00e0 partir d'un mod\u00e8le o\u00f9 une limite de CPU \u00e9tait d\u00e9finie.<\/p>\n<p><b>Swap wait<\/b> \u2013 combien de temps pendant la p\u00e9riode de mesure le vCPU a attendu une op\u00e9ration avec VMkernel Swap. Si les valeurs de ce compteur sont sup\u00e9rieures \u00e0 z\u00e9ro, alors la VM rencontre certainement des probl\u00e8mes de performance. Nous parlerons plus en d\u00e9tail de SWAP dans l'article sur les compteurs de m\u00e9moire vive.<\/p>\n<h3>ESXTOP<\/h3>\n<p>\nSi les compteurs de performance dans vCenter sont bons pour analyser les donn\u00e9es historiques, une analyse rapide du probl\u00e8me est mieux r\u00e9alis\u00e9e dans ESXTOP. Ici, toutes les valeurs sont fournies telles quelles (pas besoin de traduire), et la p\u00e9riode de mesure minimale est de 2 secondes.<br \/>\nL'\u00e9cran ESXTOP pour le CPU est appel\u00e9 en appuyant sur la touche \u00ab c \u00bb et ressemble \u00e0 ceci :<\/p>\n<p><img decoding=\"async\" alt=\"Analyse des performances des machines virtuelles dans VMware vSphere. Partie 1 : CPU\" src=\"\/wp-content\/uploads\/2019\/05\/f4f3611bc383007bdbaa0948001923c4.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPour plus de commodit\u00e9, vous pouvez ne garder que les processus des machines virtuelles en appuyant sur Shift-V.<br \/>\nPour voir les m\u00e9triques pour des c\u0153urs individuels de la VM, appuyez sur \u00ab e \u00bb et entrez le GID de la VM qui vous int\u00e9resse (30919 sur la capture d'\u00e9cran ci-dessous) :<\/p>\n<p><img decoding=\"async\" alt=\"Analyse des performances des machines virtuelles dans VMware vSphere. Partie 1 : CPU\" src=\"\/wp-content\/uploads\/2019\/05\/5f2c0226cee6e4e43128537bd4da843f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJe vais bri\u00e8vement parcourir les colonnes qui sont pr\u00e9sent\u00e9es par d\u00e9faut. Des colonnes suppl\u00e9mentaires peuvent \u00eatre ajout\u00e9es en appuyant sur \u00ab f \u00bb.<\/p>\n<p><b>NWLD (Number of Worlds)<\/b> \u2013 le nombre de processus dans le groupe. Pour d\u00e9velopper le groupe et voir les m\u00e9triques pour chaque processus (par exemple, pour chaque c\u0153ur d'une VM multicoeur), appuyez sur \u00ab e \u00bb. Si le groupe a plus d'un processus, les valeurs de m\u00e9triques pour le groupe sont \u00e9gales \u00e0 la somme des m\u00e9triques des processus individuels.<\/p>\n<p><b>%USED<\/b> \u2013 combien de cycles CPU le serveur utilise pour le processus ou le groupe de processus.<\/p>\n<p><b>%RUN<\/b> \u2013 combien de temps durant la p\u00e9riode de mesure le processus a \u00e9t\u00e9 en \u00e9tat de RUN, c'est-\u00e0-dire a ex\u00e9cut\u00e9 un travail utile. Diff\u00e8re de %USED en ce sens qu'il ne prend pas en compte l'hyper-threading, la mise \u00e0 l'\u00e9chelle de la fr\u00e9quence et le temps pass\u00e9 sur des t\u00e2ches syst\u00e8me (%SYS).<\/p>\n<p><b>%SYS<\/b> \u2013 temps pass\u00e9 sur des t\u00e2ches syst\u00e8me, par exemple : le traitement des interruptions, les op\u00e9rations d'entr\u00e9e\/sortie, la gestion du r\u00e9seau, etc. La valeur peut \u00eatre \u00e9lev\u00e9e si la VM a beaucoup d'entr\u00e9es\/sorties.<\/p>\n<p><b>%OVRLP<\/b> \u2013 combien de temps le c\u0153ur physique, sur lequel le processus de la VM s'ex\u00e9cute, a \u00e9t\u00e9 occup\u00e9 par des t\u00e2ches d'autres processus.<\/p>\n<p>Ces m\u00e9triques sont li\u00e9es entre elles de la mani\u00e8re suivante :<\/p>\n<p>%USED = %RUN + %SYS \u2014 %OVRLP.<\/p>\n<p>En g\u00e9n\u00e9ral, la m\u00e9trique %USED est plus informative.<\/p>\n<p><b>%WAIT<\/b> \u2013 combien de temps durant la p\u00e9riode de mesure le processus a \u00e9t\u00e9 en \u00e9tat d'attente. Inclut l'IDLE.<\/p>\n<p><b>%IDLE<\/b> \u2013 combien de temps durant la p\u00e9riode de mesure le processus a \u00e9t\u00e9 en \u00e9tat d'IDLE.<\/p>\n<p><b>%SWPWT<\/b> \u2013 combien de temps durant la p\u00e9riode de mesure le vCPU a attendu une op\u00e9ration avec le VMkernel Swap.<\/p>\n<p><b>%VMWAIT<\/b> \u2013 combien de temps durant la p\u00e9riode de mesure le vCPU a \u00e9t\u00e9 en \u00e9tat d'attente d'un \u00e9v\u00e9nement (habituellement d'entr\u00e9e\/sortie). Il n'y a pas de compteur similaire dans vCenter. Des valeurs \u00e9lev\u00e9es indiquent des probl\u00e8mes d'entr\u00e9e\/sortie sur la VM.<\/p>\n<p>%WAIT = %VMWAIT + %IDLE + %SWPWT.<\/p>\n<p>Si la VM n'utilise pas le VMkernel Swap, lors de l'analyse des probl\u00e8mes de performance, il est judicieux de se concentrer sur %VMWAIT, car cette m\u00e9trique ne prend pas en compte le temps o\u00f9 la VM ne faisait rien (%IDLE).<\/p>\n<p><b>%RDY<\/b> \u2013 combien de temps durant la p\u00e9riode de mesure le processus a \u00e9t\u00e9 en \u00e9tat de Ready.<\/p>\n<p><b>%CSTP<\/b> \u2013 combien de temps durant la p\u00e9riode de mesure le processus a \u00e9t\u00e9 en \u00e9tat de costop.<\/p>\n<p><b>%MLMTD<\/b> \u2013 combien de temps durant la p\u00e9riode de mesure le vCPU a \u00e9t\u00e9 en \u00e9tat de Ready en raison d'une limite de ressources fix\u00e9e.<\/p>\n<p>%WAIT + %RDY + %CSTP + %RUN = 100% \u2013 le c\u0153ur de la VM est toujours dans l'un de ces quatre \u00e9tats.<\/p>\n<h3>CPU sur l'hyperviseur<\/h3>\n<p>\nDans vCenter, il existe \u00e9galement des compteurs de performance CPU pour l'hyperviseur, mais ils n'offrent rien d'int\u00e9ressant \u2013 il s'agit simplement de la somme des compteurs de toutes les VM sur le serveur.<br \/>\nIl est plus pratique d'observer l'\u00e9tat du CPU sur le serveur \u00e0 l'onglet R\u00e9sum\u00e9 :<\/p>\n<p><img decoding=\"async\" alt=\"Analyse des performances des machines virtuelles dans VMware vSphere. Partie 1 : CPU\" src=\"\/wp-content\/uploads\/2019\/05\/15b6b9a6da136d892fbaf7f80fc206c1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPour le serveur, comme pour la machine virtuelle, il existe une Alarme standard :<\/p>\n<p><img decoding=\"async\" alt=\"Analyse des performances des machines virtuelles dans VMware vSphere. Partie 1 : CPU\" src=\"\/wp-content\/uploads\/2019\/05\/c3ae19ce3acd55cfff40d71437ee3a08.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn cas de forte charge sur le CPU du serveur, les VM fonctionnant dessus commencent \u00e0 rencontrer des probl\u00e8mes de performance.<\/p>\n<p>Dans ESXTOP, les donn\u00e9es de charge du CPU du serveur sont pr\u00e9sent\u00e9es en haut de l'\u00e9cran. En plus de la charge standard du CPU, qui est peu informative pour les hyperviseurs, il y a trois autres m\u00e9triques :<\/p>\n<p><b>CORE UTIL(%)<\/b> \u2013 charge du c\u0153ur physique du serveur. Ce compteur indique combien de temps pendant la p\u00e9riode de mesure le c\u0153ur a effectu\u00e9 du travail.<\/p>\n<p><b>PCPU UTIL(%)<\/b> \u2013 si l'hyper-threading est activ\u00e9, chaque c\u0153ur physique a deux threads (PCPU). Cette m\u00e9trique montre combien de temps chaque thread a effectu\u00e9 du travail.<\/p>\n<p><b>PCPU USED(%)<\/b> \u2013 c'est la m\u00eame chose que PCPU UTIL(%), mais prend en compte le frequency scaling (soit la r\u00e9duction de la fr\u00e9quence du c\u0153ur pour \u00e9conomiser de l'\u00e9nergie, soit l'augmentation de la fr\u00e9quence du c\u0153ur gr\u00e2ce \u00e0 la technologie Turbo Boost) et l'hyper-threading.<\/p>\n<p>PCPU_USED% = PCPU_UTIL% * fr\u00e9quence efficace du c\u0153ur \/ fr\u00e9quence nominale du c\u0153ur.<\/p>\n<p><img decoding=\"async\" alt=\"Analyse des performances des machines virtuelles dans VMware vSphere. Partie 1 : CPU\" src=\"\/wp-content\/uploads\/2019\/05\/dd8562ea91bee55bbf630358df26c217.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sur cette capture d'\u00e9cran, pour certains c\u0153urs, en raison du fonctionnement de Turbo Boost, la valeur USED d\u00e9passe 100%, car la fr\u00e9quence du c\u0153ur est sup\u00e9rieure \u00e0 la nominale.<\/i><\/p>\n<p>Quelques mots sur la fa\u00e7on dont l'hyper-threading est pris en compte. Si les processus s'ex\u00e9cutent 100% du temps sur les deux threads du c\u0153ur physique du serveur, tout en \u00e9tant \u00e0 la fr\u00e9quence nominale, alors :<\/p>\n<ul>\n<li>CORE UTIL pour le c\u0153ur sera de 100%,<\/li>\n<li>PCPU UTIL pour les deux threads sera de 100%,<\/li>\n<li>PCPU USED pour les deux threads sera de 50%.<\/li>\n<\/ul>\n<p>\nSi les deux threads n'ont pas fonctionn\u00e9 100% du temps pendant la p\u00e9riode de mesure, alors pendant les p\u00e9riodes o\u00f9 les threads ont fonctionn\u00e9 en parall\u00e8le, PCPU USED pour les c\u0153urs est divis\u00e9 par deux.<\/p>\n<p>Dans ESXTOP, il y a \u00e9galement un \u00e9cran avec les param\u00e8tres de consommation d'\u00e9nergie du CPU du serveur. Ici, vous pouvez voir si le serveur utilise des technologies d'\u00e9conomie d'\u00e9nergie : C-states et P-states. Appuy\u00e9 sur la touche \u00ab p \u00bb :<\/p>\n<p><img decoding=\"async\" alt=\"Analyse des performances des machines virtuelles dans VMware vSphere. Partie 1 : CPU\" src=\"\/wp-content\/uploads\/2019\/05\/531bf847b99f86bec0bd90e005919c79.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Probl\u00e8mes de performance standard du CPU<\/h3>\n<p>\nEnfin, je vais passer en revue les raisons typiques des probl\u00e8mes de performance du CPU de la VM et donner quelques conseils pour r\u00e9soudre ces probl\u00e8mes :<\/p>\n<p><b>Il manque de fr\u00e9quence d'horloge au c\u0153ur.<\/b> S'il n'est pas possible de transf\u00e9rer la VM sur des c\u0153urs plus performants, vous pouvez essayer de modifier les param\u00e8tres de consommation d'\u00e9nergie pour que Turbo Boost fonctionne plus efficacement.<\/p>\n<p><b>Saisonnage incorrect de la VM (trop de \/ peu de c\u0153urs).<\/b> Si vous mettez peu de c\u0153urs, la charge CPU de la VM sera \u00e9lev\u00e9e. Si vous en mettez trop, vous risquez d'avoir un co-stop \u00e9lev\u00e9.<\/p>\n<p><b>Une grande surallocation de CPU sur le serveur.<\/b> Si la VM a un Ready \u00e9lev\u00e9, r\u00e9duisez la surallocation de CPU.<\/p>\n<p><b>Topologie NUMA incorrecte sur de grandes VM.<\/b> La topologie NUMA vue par la VM (vNUMA) doit correspondre \u00e0 la topologie NUMA du serveur (pNUMA). Des diagnostics et des solutions possibles \u00e0 ce probl\u00e8me sont d\u00e9crits, par exemple, dans le livre <noindex><a rel=\"nofollow\" href=\"https:\/\/pages.rubrik.com\/host-resources-deep-dive_request.html\">\u00ab VMware vSphere 6.5 Host Resources Deep Dive \u00bb<\/a><\/noindex>. Si vous ne souhaitez pas approfondir et que vous n'avez pas de restrictions de licence sur le syst\u00e8me d'exploitation install\u00e9 sur la VM, cr\u00e9ez plusieurs sockets virtuels sur la VM avec un seul c\u0153ur chacun. Vous n'en perdrez pas beaucoup \ud83d\ude42<\/p>\n<p>C'est tout pour le CPU. N'h\u00e9sitez pas \u00e0 poser des questions. Dans la prochaine partie, je parlerai de la m\u00e9moire vive.<\/p>\n<p><b class=\"spoiler_title\">Liens utiles<\/b><noindex><a rel=\"nofollow\" href=\"http:\/\/virtual-red-dot.info\/vm-cpu-counters-vsphere\/\">http:\/\/virtual-red-dot.info\/vm-cpu-counters-vsphere\/<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/kb.vmware.com\/kb\/1017926\">https:\/\/kb.vmware.com\/kb\/1017926<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"http:\/\/www.yellow-bricks.com\/2012\/07\/17\/why-is-wait-so-high\/\">http:\/\/www.yellow-bricks.com\/2012\/07\/17\/why-is-wait-so-high\/<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/communities.vmware.com\/docs\/DOC-9279\">https:\/\/communities.vmware.com\/docs\/DOC-9279<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/www.vmware.com\/content\/dam\/digitalmarketing\/vmware\/en\/pdf\/techpaper\/performance\/whats-new-vsphere65-perf.pdf\">https:\/\/www.vmware.com\/content\/dam\/digitalmarketing\/vmware\/en\/pdf\/techpaper\/performance\/whats-new-vsphere65-perf.pdf<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/pages.rubrik.com\/host-resources-deep-dive_request.html\">https:\/\/pages.rubrik.com\/host-resources-deep-dive_request.html<\/a><\/noindex><br \/>\n<br \/>Source : <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dataline\/blog\/452884\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0415\u0441\u043b\u0438 \u0432\u044b \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0438\u0440\u0443\u0435\u0442\u0435 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043d\u0430 \u0431\u0430\u0437\u0435 VMware vSphere (\u0438\u043b\u0438 \u043b\u044e\u0431\u043e\u0433\u043e \u0434\u0440\u0443\u0433\u043e\u0433\u043e \u0441\u0442\u0435\u043a\u0430 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439), \u0442\u043e \u043d\u0430\u0432\u0435\u0440\u043d\u044f\u043a\u0430 \u0447\u0430\u0441\u0442\u043e \u0441\u043b\u044b\u0448\u0438\u0442\u0435 \u043e\u0442 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0436\u0430\u043b\u043e\u0431\u044b: \u00ab\u0412\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u0430\u044f \u043c\u0430\u0448\u0438\u043d\u0430 \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u043c\u0435\u0434\u043b\u0435\u043d\u043d\u043e!\u00bb. \u0412 \u044d\u0442\u043e\u043c \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u0440\u0430\u0437\u0431\u0435\u0440\u0443 \u043c\u0435\u0442\u0440\u0438\u043a\u0438 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0438 \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u0447\u0442\u043e \u0438 \u043f\u043e\u0447\u0435\u043c\u0443 \u00ab\u0442\u043e\u0440\u043c\u043e\u0437\u0438\u0442\u00bb \u0438 \u043a\u0430\u043a \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0442\u0430\u043a, \u0447\u0442\u043e\u0431\u044b \u043d\u0435 \u00ab\u0442\u043e\u0440\u043c\u043e\u0437\u0438\u043b\u043e\u00bb. \u0411\u0443\u0434\u0443 \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0442\u044c \u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0438\u0435 \u0430\u0441\u043f\u0435\u043a\u0442\u044b \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0445 \u043c\u0430\u0448\u0438\u043d: CPU, RAM, DISK, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25892,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34335","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=\"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\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu\" \/>\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\udd47\u0410\u043d\u0430\u043b\u0438\u0437 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u043e\u0439 \u043c\u0430\u0448\u0438\u043d\u044b \u0432 VMware vSphere. \u0427\u0430\u0441\u0442\u044c 1: CPU | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu\" \/>\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:57:43+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:57:43+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\udd47 Analyse de performance de la machine virtuelle dans VMware vSphere. Partie 1 : CPU | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu","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\udd47\u0410\u043d\u0430\u043b\u0438\u0437 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u043e\u0439 \u043c\u0430\u0448\u0438\u043d\u044b \u0432 VMware vSphere. \u0427\u0430\u0441\u0442\u044c 1: CPU | ProHoster","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/analiz-proizvoditelnosti-virtualnoj-mashiny-v-vmware-vsphere-chast-1-cpu","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:57:43+00:00","article:modified_time":"2019-10-31T18:57:43+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34335","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 18:48:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:23:17","updated":"2026-01-21 18:48:19","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\/34335","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=34335"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/34335\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/25892"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=34335"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=34335"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=34335"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}