Notre service informatique a créé une VM avec 2 CPU alloués au lieu des 4 que j'avais demandés. Leur raison est que la VM est plus performante avec 2 CPUs plutôt que 4 (selon eux). Le raisonnement est que l'hyperviseur de la VM (VMWare dans ce cas) attend que tous les CPU soient disponibles avant d'en engager un. Ainsi, il faut plus de temps pour attendre 4 CPU plutôt que 2.
Cette déclaration a-t-elle un sens ?
C'était vrai autrefois, mais ce n'est plus exclusivement vrai.
Ce à quoi ils font référence est Co-programmation stricte .
Plus important encore, alors que dans l'algorithme de co-ordonnancement strict, l'existence d'un vCPU en retard entraîne l'échec de l'algorithme de co-ordonnancement. machine virtuelle entière à être co-arrêtée. Dans l'algorithme de co-ordonnancement relaxé, un vCPU en tête de file décide si s'il doit s'arrêter lui-même en se basant sur le skew par rapport au vCPU frère le plus lent.
Maintenant, si l'hôte n'a que 4 threads, alors il serait stupide de les allouer tous. Si il possède deux processeurs et 4 threads par processeur, alors vous pourrait Vous ne voulez pas allouer tout le contenu d'un seul processeur, car votre hyperviseur doit essayer de garder les vCPU sur le même nœud NUMA pour rendre l'accès à la mémoire plus rapide, et vous rendez ce travail plus difficile en allouant un socket entier à une seule VM (voir page 12 du PDF ci-dessus).
Donc il y a des scénarios où moins de vCPUs peut sont plus performants que d'autres, mais ce n'est pas vrai 100 % du temps.
Tout cela dit et fait, j'alloue très rarement plus de 3 vCPUs par invité. Tout le monde en reçoit 2 par défaut, 3 s'il s'agit d'une charge de travail importante, et 4 pour des choses comme les serveurs SQL ou les VM de traitement par lots très lourdes, ou un serveur terminal avec beaucoup d'utilisateurs.
Soit dit en passant, même en dehors des problèmes de virtualisation, il est généralement difficile d'écrire des logiciels qui exploitent le parallélisme. Si vos concepteurs de logiciels ne sont pas assez bons, il peut être préférable d'avoir quatre hôtes virtuels exécutant chacun une instance du logiciel plutôt qu'un hôte exécutant quatre fils d'exécution.
@Luaan La boîte est équipée d'un serveur SQL, je suppose donc qu'il y a de bons informaticiens sur place.
@AngryHacker oui le serveur SQL peut utiliser les 4 cœurs de manière très efficace en supposant que vous ayez la puissance appropriée. MAXDOP des paramètres. Toutefois, en fonction de la charge de travail, un serveur SQL trop sollicité est souvent le signe d'une mauvaise conception de la base de données - mauvais index, pas d'index en grappe, trop d'index, pas d'optimisation, etc.
Cela dépend en grande partie de l'hyperviseur sous-jacent et des administrateurs qui le gèrent, laissez-moi vous expliquer :
Que pouvez-vous en tirer ? Créez toujours des VM avec des ressources minimales et augmentez-les si nécessaire. Faites toujours évoluer votre application vers l'extérieur plutôt que vers l'intérieur et vous serez en mesure de l'exécuter n'importe où.
En raison du verrouillage qui peut être expérimenté avec l'hyperviseur, il est effectivement vrai que 2 CPU peuvent être plus rapides que 4 CPU.
Oui, l'affirmation est logique en général. Cependant, c'est quelque chose que vous devriez tester pour votre configuration et votre charge de travail exactes. Parfois, il est préférable d'avoir plus de processeurs si vous pouvez en tirer parti. Cependant, si vous n'avez pas beaucoup de parallélisme, une VM configurée avec moins de CPU sera souvent légèrement plus performante car elle évite les ralentissements dus aux pauses du CPU Ready State.
J'ai réduit les vCPUs sur un certain nombre de nos VMs et j'ai constaté une amélioration du débit sur la majorité d'entre elles. Une poignée d'entre elles ont empiré et ont dû être augmentées en nombre de vCPU.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
