Cœurs de CPU virtualisés vs threads

Nous avons un système hôte KVM sur Ubuntu 9.10 avec un processeur Xeon quadricœur plus récent avec hyperthreading. Comme détaillé sur la page produit d'Intel , le processeur a 4 cœurs mais 8 threads. / proc / cpuinfo et htop répertorient tous les deux 8 processeurs, bien que chacun indique 4 cœurs dans cpuinfo. KVM / QEMU signale également 8 VCPU disponibles pour assigner aux invités.

Ma question est lorsque j'alloue des VCPU à des invités VM, dois-je allouer par cœur ou par thread? Étant donné que KVM / QEMU signale que le serveur a 8 VCPU à allouer, dois-je aller de l'avant et configurer un invité pour utiliser 4 CPU alors que je l'aurais précédemment configuré pour utiliser 2 (en supposant que 4 VCPU au total soient disponibles)? J'aimerais tirer le meilleur parti du matériel hôte sans surallouer.

Mise à jour: la réponse de Chopper3 est sans aucun doute la bonne approche. Cependant, j'aimerais toujours entendre des experts en matériel qui pourraient expliquer les aspects de performance des threads par rapport aux cœurs ... n'importe qui?

Définissez le plus petit nombre de processeurs virtuels dont vos serveurs ont besoin pour exécuter leur fonction, ne les surallouez pas ou vous pourriez facilement ralentir vos machines virtuelles.

En règle générale, HT fonctionne bien sur les charges de travail plus lourdes sur les E / S - le processeur peut planifier davantage de tâches de traitement à partir de la file d'attente de l'autre processeur virtuel tandis que le premier processeur virtuel attend sur les E / S. Vraiment, tous les sous-systèmes HT que vous obtenez sont une commutation de contexte accélérée par le matériel - qui est le modèle de charge de travail qui est également utilisé lors du passage d'une machine virtuelle à l'autre. Ainsi, HT réduira (généralement) un peu le ralentissement lorsque vous avez plus de machines virtuelles que de cœurs, à condition que chaque machine virtuelle dispose d'un cœur virtuel.

L'affectation de plusieurs processeurs virtuels à une machine virtuelle peut améliorer les performances si les applications de la machine virtuelle sont écrites pour le threading, mais cela rend également la vie de l'hyperviseur plus difficile; il doit allouer du temps sur 2 ou 4 processeurs à la fois - donc si vous avez un processeur quadricœur et une machine virtuelle quad-vCPU, une seule machine virtuelle peut être planifiée pendant cette tranche horaire (alors qu'elle peut exécuter 4 machines virtuelles à processeur unique unique vCPU immediatement).

C'est assez délicat. Selon les charges, HT peut augmenter les performances de ~ 30% ou les diminuer. Normalement, je conseille de ne pas allouer plus de processeurs virtuels que vous avez de cœurs physiques, à une seule machine virtuelle, mais si la machine virtuelle est plutôt inactive (et bien sûr, une telle machine virtuelle ne nécessitera pas vraiment trop de processeurs), elle peut être abandonnée comme de nombreux processeurs virtuels que vous avez des threads. Vous ne voulez pas vraiment donner à une seule machine virtuelle plus de vCPU que vous n'en avez de cœurs programmables . Et dans tous les cas, les conseils de @ Chopper3 sont bons - ne donnez pas à la VM plus de v-CPU qu'elle n'en a absolument besoin.

Ainsi, en fonction de la charge et de la criticité de vos machines virtuelles, vous ne sur-allouez pas du tout, vous vous en tenez au nombre de cœurs physiques ou vous montez aussi haut que le nombre de threads par machine virtuelle.

Maintenant, en abordant la question de HT, c'est généralement une bonne chose d'avoir, en particulier lorsque vous validez plus de vCPU sur vos machines virtuelles que vous n'avez de cœurs physiques ou même de threads, car cela facilite la planification de ces vCPU par le planificateur Linux.

Une dernière chose, avec kvm, un vCPU affecté à une machine virtuelle n'est qu'un processus sur l'hôte, planifié par le planificateur Linux, de sorte que toutes les optimisations normales que vous pouvez faire ici s'appliquent facilement. De plus, le paramètre cores / sockets est juste la façon dont ce processus sera affiché pour le système d'exploitation invité de la machine virtuelle, sur l'hôte, il ne s'agit que d'un processus, quelle que soit la façon dont la machine virtuelle le voit.

Je pense que pour développer la réponse de Chopper3: si les systèmes sont pour la plupart inactifs en cpu, n'attribuez pas un tas de vcpu, s'ils sont intenses en cpu, faites très attention à ne pas sur-utiliser. Vous devriez pouvoir allouer un total de 8 vCPU sans contention. Vous pouvez surallouer, mais si vous le faites, assurez-vous qu'aucun invité, en particulier un invité gourmand en processeur, ne dispose de 8 vcpu, sinon vous aurez des conflits. Je ne sais pas si le mécanisme du planificateur KVM est plus précis que cela.

Ce qui précède est basé sur la compréhension suivante du vCPU par rapport au CPU épinglé, mais également sur l'hypothèse que KVM permettra à un seul invité (ou plusieurs invités) de monopoliser tout le CPU réel des autres si vous lui allouez (/ eux) suffisamment de threads. vCPU ~ thread hôte, CPU invité CPU = hôte Core, CPU invité (N'ont pas joué avec vCPU mixte et CPU épinglé sur le même invité, car je n'ai pas Hyperthreading.)