Meilleure pratique: vCPU par cœur physique

27

J'essaie de trouver de la documentation ou des guides de bonnes pratiques pour la virtualisation en ce qui concerne le provisionnement de processeurs virtuels par cœur physique (d'un processeur). Si cela importe, je regarde vmWare pour l'implémentation de la virtualisation. Par exemple, un processeur Intel Xeon peut avoir 4, 8, etc. cœurs. Je souhaite en savoir plus sur l'approvisionnement au-delà d'un seul vCPU par cœur physique. Le fournisseur avec qui je parle pense définitivement qu'un seul cœur peut être provisionné en plusieurs processeurs virtuels.

Ce que je vois couramment dans mes recherches jusqu'à présent, c'est: "Eh bien, cela dépend de votre application." Et dans ce cas, mon application édite du code, compile / lie, teste et gère la configuration. Bien sûr, toutes les machines virtuelles n'ont pas besoin d'être configurées avec plusieurs vCPU par cœur, mais dans le cas général.

— Dr. Watson
source

24

Un seul CPU physique peut être utilisé comme autant de vCPU. Vous manquez rarement de ressources CPU dans les solutions de virtualisation. La RAM et le stockage sont toujours les facteurs limitants ...

Rappelez-vous, dans VMware, l'utilisation du CPU est représentée en MHz utilisé, pas les cœurs ... À moins que vous ne fixiez tous vos CPU virtuels à 100% EN TOUT TEMPS , je ne pense pas que votre fournisseur soit correct.

Regardons le cluster de systèmes suivant ...

9 hôtes ESXi.
160 machines virtuelles
104 cœurs de processeur physiques sur le cluster.
Le profil moyen d'une machine virtuelle est: 4 vCPU et 4 Go à 18 Go de RAM.
Le processeur peut être sursouscrit en toute sécurité ... mais rappelez-vous, il peut également être limité, réservé et priorisé au niveau de la machine virtuelle.

d'un autre cluster actif - 3 hôtes 42 machines virtuelles entrez la description de l'image ici

— ewwhite
source

4

Après avoir vu 3936 migrations vMotion, je ne me sens pas trop mal pour nos 1 200

— Mark Henderson

2

Hier, je regardais les statistiques de notre cluster VM qui corroborent les chiffres donnés par @ewwhite. Nous avons 3 hôtes, totalisant 24 processeurs et 55 GHz. Nous avons 59 machines virtuelles avec un total de 79 processeurs virtuels alloués. Selon les statistiques de vSphere, au cours des 6 derniers mois, nous avons en moyenne un peu plus de 14 GHz utilisés (min 9 GHz, max 25 GHz), et pendant ce temps, il n'y avait aucun conflit de nombre de cœurs CPU.

— Paul Gear

7

Pour développer l'écriture d'ewwhite, à moins que vous n'ayez des applications qui peuvent explicitement tirer parti de plusieurs vCPU ou de plusieurs cœurs par vCPU, il n'y a absolument aucun avantage à allouer plusieurs vCPU / cœurs à une machine virtuelle. En fait, le plus souvent, vous vous retrouverez avec des performances inférieures au lieu de s'exécuter sur un seul vCPU auquel un cœur est affecté, en partie en raison de la surcharge de planification requise pour exécuter plusieurs vCPU.

FWIW, dans un environnement VDI, le nombre souvent cité est de 5 processeurs virtuels par cœur physique. Bien sûr, cela tient compte des ordinateurs de bureau. Si vos machines virtuelles sont très occupées à compiler du code tout le temps, vous ne pourrez peut-être pas installer 5 vCPU par cœur physique.

La raison pour laquelle tant de gens disent que "cela dépend" est parce que c'est vraiment le cas. Examinez vos valeurs CPU Ready et décidez ensuite si vous pouvez augmenter la charge CPU sur un système particulier. CPU Ready est une mesure du vCPU prêt à exécuter une commande, mais il doit attendre que le temps CPU physique soit disponible.

Dans votre cas, si vous compilez de gros programmes, il est tout à fait possible que vos machines virtuelles aient réellement besoin de beaucoup de temps processeur. Comme l'a noté ewwhite, normalement la virtualisation a tendance à être contrainte sur les E / S disque et RAM plutôt que sur le processeur.

— Extracteur de réalité
source

13

absolutely zero benefit in allocating multiple vCPUs/cores to a VM- pas tout à fait correct. Nous avons une application à un seul thread qui se bloquait sur une base hebdomadaire. Lorsqu'un seul processeur virtuel était à 100%, il était impossible d'accéder à ce système et nous avons dû effectuer une réinitialisation du niveau d'hyperviseur de la machine virtuelle. Nous avons ajouté un 2e vCPU et lorsque l'application s'est bloquée, nous avons pu facilement entrer et tuer le fil incriminé. C'est un peu un cas de bord vrai, mais vous ne pouvez jamais traiter en absolu.

— Mark Henderson

4

Ce que Mark a écrit est la raison pour laquelle nous utilisons deux cœurs comme limite inférieure pour chaque machine virtuelle - peu importe qu'ils en aient besoin ou non.

— Nils

2

La valeur prête est la meilleure façon de savoir si vous avez trop provisionné votre hôte, votre valeur prête doit être aussi faible que possible. Il s'agit du% de temps pendant lequel une machine virtuelle est "prête" à utiliser un cycle de processeur, mais doit attendre car le processeur est occupé par une autre tâche. Pour expliquer pourquoi le fait de donner à votre VM de nombreux cœurs peut avoir un impact sur les performances, j'utiliserai un exemple simple: si j'ai 4 cœurs physiques et 4 Vms, si vous avez 3 VM avec 2 cœurs et un VM avec 4 cœurs, vos petites VM obtiendront réellement plus de cycles, car ils peuvent mieux "s'adapter" en multiples. Allez aussi conservateur que possible avec votre vcpus!

— Rqomey

@MarkHenderson Je peux voir comment cela pourrait être bénéfique, et quelque chose comme ça pourrait potentiellement arriver au gars qui a posé la question puisqu'il travaille avec des compilateurs.

— Extracteur de réalité

@Nils Je pense que donner à chaque VM 2 cœurs qu'il y ait un besoin commercial ou non est une très mauvaise idée. Cela pourrait facilement vous affecter négativement à bien des égards, la taille de l'emplacement, pas assez de cœurs disponibles pour redémarrer / basculer, les performances perdues en raison de ce que Rqomey a écrit, juste d'innombrables autres choses. Vous pouvez à peu près toujours accéder à votre machine virtuelle via vCenter et DCUI.

— Extracteur de réalité

3

Le problème sous-jacent est fondamentalement le même que pour la planification de processus sur un système physique. Tant que la charge du système est inférieure au nombre de cœurs (ou même de processeurs logiques, en cas d'HyperThreading), tout va bien et les processeurs peuvent gérer la charge.

Donc, tant que la charge simultanée sur tous les processeurs virtuels utilisés ne dépasse pas la charge qui peut être gérée par vos cœurs physiques, tout va bien.

Pour vos demandes, seule la compilation est un travail gourmand en ressources processeur, qui n'est nécessaire que de temps en temps. Pour les VM de compilateur, nous allouons autant de CPU que possible. Donc, s'il est nécessaire de compiler, cela se fera aussi rapidement que possible (si votre compilateur prend en charge la compilation parallèle).

Cela peut ne pas être vrai pour une machine virtuelle de compilation qui est sous une charge constante (par exemple, si vous fournissez un service Internet pour effectuer des compilations et qui est constamment utilisé).

— Nils
source

2

Une règle générale que j'ai vue (peut-être dans la documentation de VMware) est de ne pas allouer plus de cœurs à une machine virtuelle qu'il n'en existe physiquement sur l'hôte, car cela entraînerait l'émulation de plusieurs vCores sur un seul cœur, ajoutant une surcharge inutile.

— Paul Gear
source

1

Et l'inverse? Que faire si j'ai un Xeon à 6 cœurs et que j'alloue seulement 4 cœurs dans la machine virtuelle? Quelle serait alors la performance? Le système VM pourra-t-il récupérer la puissance des 6 cœurs physiques ou sera-t-il limité à 4?

— Overmind

Si vous ne lui donnez que 4 cœurs, il n'aura accès qu'à 4 cœurs à la fois. Mais ma compréhension (non confirmée) est que ces 4 cœurs virtuels peuvent être alloués sur 4 des 6 cœurs physiques, sauf si vous avez configuré l'épinglage.

— Paul Gear