Quelle est la contention de trop dans VMware?


21

Depuis un certain temps maintenant, j'essaie de comprendre pourquoi bon nombre de nos systèmes critiques reçoivent des rapports de «lenteur» allant de légère à extrême. J'ai récemment tourné mon regard vers l'environnement VMware où tous les serveurs en question sont hébergés.

J'ai récemment téléchargé et installé la version d'essai du pack d'administration Veeam VMware pour SCOM 2012, mais j'ai du mal à croire (et mon patron aussi) les chiffres qu'il me rapporte. Pour essayer de convaincre mon patron que les chiffres qu'il me dit sont vrais, j'ai commencé à regarder le client VMware lui-même pour vérifier les résultats.

J'ai regardé cet article VMware KB ; spécifiquement pour la définition de Co-Stop qui est définie comme:

Durée pendant laquelle une machine virtuelle MP était prête à fonctionner, mais a subi un retard en raison d'un conflit de planification de co-vCPU

Que je traduis

Le système d'exploitation invité a besoin de temps de l'hôte, mais doit attendre que les ressources deviennent disponibles et peut donc être considéré comme "ne répondant pas"

Cette traduction semble-t-elle correcte?

Si c'est le cas, voici où j'ai du mal à croire ce que je vois: l'hôte qui contient la majorité des machines virtuelles qui sont "lentes" affiche actuellement une moyenne de CPU Co-stop de 127 835,94 millisecondes!

Est-ce à dire qu'en moyenne les VMs sur cet hôte doivent attendre 2+ minutes pour le temps CPU ???

Cet hôte possède deux processeurs à 4 cœurs et il a un invité de processeur 1x8 et des invités de processeur 14x4.


D'après ma compréhension: pour éviter certains problèmes, tous les processeurs virtuels d'une machine virtuelle doivent être exécutés en même temps. En cas de conflit, certaines machines virtuelles peuvent fonctionner très lentement. Notez que l'attribution de plus de vCPU aux machines virtuelles pour essayer d'améliorer les performances lorsque c'est le problème aggravera les choses.
Brian

Cet hôte a deux processeurs 4 cœurs et il a un invité processeur 1x8 et des invités processeur 14x4.
Chuck Herrington

Pourquoi tant d'invités ont-ils 4 configurations de vCPU?
ewwhite

6
La contention de co-programmation CPU vous tue. Vous devez réduire le nombre de processeurs virtuels ou déplacer certaines machines virtuelles hors de ce système.
Brian

@ChuckHerrington Vous devez suivre ou marquer une réponse.
ewwhite

Réponses:


17

Je peux décrire certaines des expériences que j'ai eues dans ce domaine ...

Je ne pense pas que VMware fasse un travail adéquat pour éduquer les clients ( ou les administrateurs ) sur les meilleures pratiques, ni mettre à jour les anciennes meilleures pratiques à mesure que leurs produits évoluent. Cette question est un exemple de la façon dont un concept de base comme l'allocation de vCPU n'est pas entièrement compris. La meilleure approche consiste à commencer petit, avec un seul vCPU, jusqu'à ce que vous déterminiez que la machine virtuelle nécessite plus.

Pour l'OP, le serveur hôte ESXi possède deux processeurs quadricœurs, ce qui donne 8 cœurs physiques.

La disposition de la machine virtuelle décrite est de 15 invités au total; Systèmes 1 x 8 vCPU et 14 x 4 vCPU. C'est beaucoup trop engagé, en particulier avec l'existence d'un seul invité avec 8 processeurs virtuels . Cela n'a aucun sens. Si vous avez besoin d'une machine virtuelle aussi grande, vous avez probablement besoin d'un plus grand serveur.

Veuillez essayer de dimensionner correctement vos machines virtuelles. Je suis pratiquement certain que la plupart d'entre eux peuvent vivre avec 2 processeurs virtuels. L'ajout de CPU virtuels n'accélère pas les choses, donc si c'est un remède à un problème de performances, c'est la mauvaise approche à adopter.

Dans la plupart des environnements, la RAM est la ressource la plus contrainte. Mais le CPU peut être un problème s'il y a trop de conflits. Vous en avez la preuve. La RAM peut également être un problème si trop de ressources sont allouées aux machines virtuelles individuelles .

Il est possible de surveiller cela. La métrique que vous recherchez est "CPU Ready%". Vous pouvez y accéder depuis le client vSphere en sélectionnant une machine virtuelle et va Performance> Overview> CPU Graph.

  • Moins de 5% CPU Ready - vous allez bien.
  • 5-10% CPU Ready - Gardez un œil attentif sur l'activité.
  • Plus de 10% CPU Ready - Pas bon.

Notez la ligne jaune dans le graphique ci-dessous. entrez la description de l'image ici

Pourriez-vous vérifier cela sur vos machines virtuelles problématiques et en faire rapport?


Je viens de regarder le graphique d'un serveur d'échange que nous avons sur cet hôte surchargé. Mon graphique ressemble à l'inverse du vôtre. L'utilisation du processeur oscille autour de 25% et les pics CPU Ready atteignent jusqu'à 200%, mais en moyenne autour de 100%.
Chuck Herrington

@ChuckHerrington Veuillez réduire les ressources de la machine virtuelle 8 vCPU et mesurer à nouveau.
ewwhite

La seule préoccupation à ce sujet est que l'invité 8 cpu est l'un des principaux serveurs de base de données du serveur SQL de production. Nous avions essayé de le réduire à 4 auparavant et les choses se sont mal passées. Je suppose que nous ferions mieux d'essayer à nouveau.
Chuck Herrington

Vous ne pouvez pas avoir une machine virtuelle 8 vCPU sur un serveur avec 8 cœurs au total.
ewwhite

@ewwhite vous pouvez malheureusement, vous ne devriez pas, mais vous pouvez.
Rqomey

46

Vous déclarez dans les commentaires que vous avez un hôte ESXi double quadricœur et que vous exécutez une machine virtuelle 8vCPU et quatorze machines virtuelles 4vCPU.

Si tel était mon environnement, je considérerais cela comme excessivement surapprovisionné . Je voudrais tout au plus mettre quatre à six invités 4vCPU sur ce matériel. (Cela suppose que les machines virtuelles en question ont une charge qui les oblige à avoir le plus haut nombre de vCPU.)

Je suppose que vous ne connaissez pas la règle d'or ... avec VMware, vous ne devez jamais attribuer à une machine virtuelle plus de cœurs qu'elle n'en a besoin. Raison? VMware utilise une co-planification quelque peu stricte, ce qui rend difficile pour les machines virtuelles d'obtenir du temps CPU, sauf s'il y a autant de cœurs disponibles que la machine virtuelle est affectée. Cela signifie qu'une machine virtuelle 4vCPU ne peut effectuer 1 unité de travail que si 4 cœurs physiques sont ouverts au même moment. En d'autres termes, il est préférable sur le plan architectural d'avoir une machine virtuelle 1vCPU avec 90% de charge CPU, puis d'avoir une machine virtuelle 2vCPU avec 45% de charge par cœur.

Alors ... TOUJOURS créer des VM avec un minimum de vCPU, et ne les ajouter que lorsque cela est jugé nécessaire.

Pour votre situation, utilisez Veeam pour surveiller l'utilisation du processeur sur vos invités. Réduisez le nombre de vCPU autant que possible. Je serais prêt à parier que vous pouvez passer à 2vCPU sur presque tous vos invités 4vCPU existants.

Certes, si toutes ces machines virtuelles ont réellement la charge du processeur pour exiger le nombre de vCPU dont elles disposent, il vous suffit d'acheter du matériel supplémentaire.


20
Cette réponse, je l'aime, une autre! (écrase une tasse de café au sol)
MonkeyZeus

2
Une chose à ajouter .. Configurez une alerte pour CPU% ready. davidklee.net/articles/sql-server-articles/…
Stewpudaso

1
Cela ne devrait-il pas être un sous-approvisionnement?
user253751

3
Cette idiotie VMWare est-elle toujours en place? Hyper-V avait le même - dans la version initiale et il a été géré dès que possible. Désormais, les cœurs sont programmés indépendamment. Je ne peux pas imaginer que ce soit toujours le cas pour VmWare dans la version actuelle.
TomTom

2
@TomTom: selon serverfault.com/a/642316/58957, la "co-programmation stricte" était utilisée dans les versions antérieures à 3.x (il y a plus de 10 ans!), Mais Internet en est encore plein. Néanmoins, la recommandation d'augmenter uniquement le nombre de processeurs virtuels est nécessaire.
Nickolay

2

Les 127 835,94 millisecondes sont une somme et vous devez diviser par le temps d'échantillonnage pour obtenir les valeurs% RDY correctes. Il semble que vous obteniez déjà les lectures% RDY correctes maintenant. Vous pouvez aller assez haut avec le rapport vCPU / CPU physique, mais pas comme vous le faites.

Vous avez beaucoup trop de machines virtuelles vCPU quad et même une machine virtuelle 8 vCPU. Certaines réponses de qualité discutent déjà du bon dimensionnement et de certaines ramifications de la non consolidation des cycles à moins de processeurs virtuels. La seule chose que je voulais clarifier est que, bien qu'il ne soit plus vrai qu'une machine virtuelle doive attendre que le nombre de processeurs physiques égal à son nombre de processeurs virtuels devienne disponible avant de pouvoir traiter une instruction, c'est très préjudiciable. d'avoir un surprovisionnement de cette ampleur avec le rapport des machines virtuelles multi-vCPU aux cœurs physiques. 64 processeurs virtuels sur 8 cœurs dépassent largement le rapport maximum de 4 pour 1. Je suppose que vous avez HT sur ces processeurs, vous avez donc 16 cœurs logiques? Cela pourrait être OK avec 1 et 2 machines virtuelles vCPU qui ont une charge légère, mais si vous avez une lourde charge sur les machines virtuelles, cela serait difficile à accomplir.

Pour info Les processeurs HT ne sont pas utilisés dans les calculs% CPU utilisé - ce qui signifie que si vous avez 32 cœurs logiques fonctionnant à 2,4 Ghz sur un serveur, vous êtes à 100% d'utilisation lorsque vous atteignez 38,4 GHz. Donc, lorsque vous voyez les moyennes de charge affichant plus de 1,0, c'est pourquoi.

Voici un hôte ESXi qui exécute un rapport de 3,5 à 1 vCPU / CPU physique (y compris les cœurs HT) avec un% RDY moyen de 3%.

11:13:49pm up 125 days  7:20, 1322 worlds, 110 VMs, 110 vCPUs; CPU load average: 1.34, 1.43, 1.37


  %USED    %RUN    %SYS   %WAIT %VMWAIT    %RDY   %IDLE  %OVRLP   %CSTP  %MLMTD  %SWPWT 
  13.51   15.87    0.50  580.17    0.03    4.67   66.47    0.29    0.00    0.00    0.00 
  15.24   18.64    0.43  491.54    0.04    4.65   63.70    0.43    0.00    0.00    0.00 
  13.44   16.40    0.44  494.10    0.02    4.33   66.24    0.48    0.00    0.00    0.00 
  13.75   16.30    0.51  494.26    0.32    4.32   66.06    0.35    0.00    0.00    0.00 
  17.56   20.72    0.58  489.35    0.04    4.31   60.76    0.45    0.00    0.00    0.00 
  13.82   16.43    0.50  494.12    0.07    4.31   66.26    0.26    0.00    0.00    0.00 
  13.65   16.81    0.49  493.81    0.03    4.21   65.93    0.37    0.00    0.00    0.00 
  13.73   16.51    0.42  493.63    0.09    4.06   66.24    0.29    0.00    0.00    0.00 
  13.89   16.37    0.55  580.61    0.04    3.95   66.69    0.28    0.00    0.00    0.00 
  14.02   17.00    0.33  494.11    0.03    3.93   66.10    0.29    0.00    0.00    0.00 
  13.44   15.84    0.49  495.17    0.04    3.87   67.24    0.27    0.00    0.00    0.00 
  13.59   15.84    0.50  580.27    0.04    3.81   67.24    0.44    0.00    0.00    0.00 
  17.10   19.86    0.50  490.97    0.04    3.74   62.21    0.39    0.00    0.00    0.00 
  13.32   15.77    0.50  495.34    0.03    3.73   67.47    0.27    0.00    0.00    0.00 
  13.43   16.15    0.48  494.95    0.05    3.72   67.09    0.38    0.00    0.00    0.00 
  13.44   16.47    0.49  580.88    0.04    3.72   66.81    0.40    0.00    0.00    0.00 
  13.71   17.00    0.29  494.13    0.03    3.71   66.26    0.37    0.00    0.00    0.00 
  17.34   20.41    0.39  490.50    0.05    3.70   61.70    0.37    0.00    0.00    0.00 
  13.42   16.19    0.50  495.07    0.03    3.66   67.15    0.38    0.00    0.00    0.00 
  13.56   16.23    0.48  494.97    0.03    3.60   67.12    0.30    0.00    0.00    0.00 
  14.95   17.53    0.42  578.82    0.09    3.57   65.72    0.35    0.00    0.00    0.00 
  13.44   16.07    0.56  581.14    0.04    3.54   67.34    0.40    0.00    0.00    0.00 
  17.19   21.27    0.37  575.41    0.04    3.44   61.08    0.51    0.00    0.00    0.00 
  13.57   16.99    0.30  580.64    0.01    3.37   66.69    0.38    0.00    0.00    0.00 
  13.79   16.25    0.43  495.25    0.04    3.35   67.39    0.39    0.00    0.00    0.00 
  11.90   14.67    0.30  496.86    0.02    3.31   69.00    0.36    0.00    0.00    0.00 
  17.13   19.28    0.56  491.83    0.03    3.30   63.26    0.48    0.00    0.00    0.00 
  14.01   16.17    0.50  495.56    0.01    3.30   67.66    0.39    0.00    0.00    0.00 
  16.86   20.16    0.57  491.19    0.05    3.20   62.44    0.43    0.00    0.00    0.00 
  14.94   17.46    0.42  580.05    0.08    3.16   66.24    0.40    0.00    0.00    0.00 
  14.56   16.94    0.36  494.86    0.08    3.14   66.91    0.42    0.00    0.00    0.00

......

1

Depuis, nous avons installé Veeam ONE, qui nous a permis de savoir où se situent nos problèmes de performances. En examinant l'écran des goulots d'étranglement du processeur dans Veeam ONE, puis en utilisant le dépannage d'une machine virtuelle qui a cessé de répondre: comparaison de l'utilisation de VMM et du processeur invité comme référence, nous avons déterminé où se trouve notre conflit "inacceptable".

Une petite astuce que je voulais partager spécifiquement est que dans un cas, je ne pouvais pas éliminer les conflits de CPU tant que je n'avais pas supprimé l'instantané qui se trouvait sur la machine virtuelle. J'espère que cela aide quelqu'un.


Oh mon. Il y avait aussi des instantanés en cours d'exécution?
ewwhite
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.