VirtualBox: Est-ce une mauvaise idée d'attribuer plus de cœurs de processeur virtuels que de nombre de cœurs de processeur physiques

41

Comme je dispose d’un processeur compatible Hyper-Threading , je me demande s’il est une mauvaise idée d’attribuer plus de cœurs de processeur virtuels que de nombre de cœurs de processeur physiques, comme le suggère l’avertissement suivant:

Avertissement VirtualBox

Transcription:

Le nombre de processeurs virtuels présents sur le système hôte est supérieur au nombre de processeurs virtuels attribués à la machine virtuelle. Cela est susceptible de dégrader les performances de votre machine virtuelle. Veuillez envisager de réduire le nombre de processeurs virtuels.

Quelqu'un peut-il mettre un raisonnement sur ce sujet?

EDIT1:

Le processeur en question est Intel Core i7-4700HQ, Ark Intel , Benchmark du processeur.

EDIT2:

En supposant qu'il n'y ait pas de matériel obsolète, comme un disque dur (au lieu d'un SSD), et / ou une faible mémoire RAM (16 Go ici, minimum vm.swappiness, 4 Go pour cette machine virtuelle), etc.

LinuxSecurityFreak
la source
2
L'avertissement est raisonnablement précis et ne doit pas être ignoré, sauf si les performances en temps réel ne sont pas importantes, ou si seul un chargement minimal (logiciel) sera soumis à la machine virtuelle. Voir Qu'est-ce qu'un noyau de processeur logique (par opposition à un noyau de processeur physique)?
agc
Comme dit la mise en garde. Les choses pourraient en fait être plus rapides avec moins de processeurs dans la VM.
Rui F Ribeiro
Vous ne devriez jamais aller dans la ligne rouge. Vous pouvez utiliser 4 "cœurs" sur un processeur à 4 cœurs HT. Pour la RAM, 50% de votre RAM devrait suffire, même si la partie verte dépasse cette limite.
cylgalad
Dans Virtualbox, les "cœurs" sont tous les threads. Ainsi, si vous avez un processeur avec 4 cœurs et Hyperthreading, cela équivaut à 8 "cœurs". Vous pouvez donc configurer jusqu'à 4 cœurs virtuels dans une même machine virtuelle si vous l'exécutez seul. C'est ce que je fais tout le temps et ça marche très bien.
cylgalad
Qu'est-ce que je dois prouver? La ligne rouge correspond à plus de 4 "cœurs" pour moi, je ne vais jamais au-delà et je ne fais jamais fonctionner 2 VM en même temps. Si vous préférez risquer de faire planter votre ordinateur en donnant tout le processeur à la machine virtuelle et que vous ne faites rien en dehors de la machine virtuelle, cela peut être correct.
cylgalad

Réponses:

30

Matériel / système d'exploitation / logiciel

Hôte : Linux Mint 18 Cinnamon 64 bits (entièrement mis à jour); Version du noyau 4.4.0-47-generic

Invité : Windows 8.1 Pro 64-bit (entièrement mis à jour)

Processeur : Intel Core i7-4700HQ , (cache de 6 Mo, 4 cœurs physiques ou 8 utilisant l’hyper-threading), test de performance du processeur

VirtualBox : Version 5.1.10 r112026 (Qt5.5.1)

Guest Additions : Installé et à jour

Outil d'évaluation des performances n ° 1 : WinRAR version 5.40 finale 64 bits

Outil d'évaluation des performances n ° 2 : VeraCrypt version 1.19 finale 64 bits


Préparation

Dans les deux cas, j'ai attendu après le démarrage que le processeur, la mémoire vive et le lecteur de disque soient à un niveau stable près de zéro.


Méthode

  1. Cloner la machine virtuelle d'origine pour en avoir deux identiques.
  2. Depuis le redémarrage, Antivirus est signalé au bas de la réponse et met à jour WinRAR dans les deux cas, d’une version bêta à la version finale.
  3. J'ai fait la même préparation que précédemment.
  4. La machine virtuelle fonctionnait au premier plan, sans aucune autre application gourmande en temps de calcul, j'ai désactivé ce que je pouvais pour que le test ne soit pas influencé.
  5. Pour inclure la mise en cache potentielle à l'intérieur ou à l'extérieur du système, j'ai exécuté le même test deux fois en conséquence. L'avantage étant presque nul.

Résultats

WinRAR

  1. 4 noyaux => 7,5 minutes ( moins de temps est préférable)

    WinRAR avec 4 cœurs activés

    WinRAR avec 4 cœurs activés, 1,5 Go traité en 7,5 minutes.

  2. 8 cœurs => 4,5 minutes ( moins de temps est préférable)

    WinRAR avec 8 cœurs activés

    WinRAR avec 8 cœurs activés, 1,5 Go traité en 4,5 minutes.


VeraCrypt

  1. 4 cœurs => vitesse 2,6 Gb / s ( plus vite est préférable)

    VeraCrypt avec 4 cœurs activés

    VeraCrypt avec 4 noyaux activés, AES (AES-NI) HW-accélérée vitesse 2,6 Gio / s.

  2. 8 cœurs => vitesse 3,9 GiB / s ( une vitesse supérieure est meilleure)

    VeraCrypt avec 8 cœurs activés

    VeraCrypt à 8 noyaux activés, AES (AES-NI) HW-accélérée vitesse 3,9 Gio / s.


Conclusion

Je pourrais faire autant de tests que nécessaire. Mais je pense que si ces deux-là, dont l’un est un test de compression assez complexe, le second étant un ensemble de tests de cryptage assez complexes, quel serait l’intérêt.

Les deux points de repère montrent une différence marquée. Je ne vois aucune raison de croire que leurs résultats sont inexacts, car j'ai suivi une préparation et une méthode assez rigoureuses. De plus, ces tests ont été effectués dans la RAM pour éliminer les goulots d'étranglement des E / S. De mon point de vue, l'avertissement mentionné dans la question peut s'appliquer à certaines conditions, mais certainement pas à toutes. Après avoir partagé avec vous ces résultats assez remarquables, je suis certain que vous conviendrez avec moi que cet avertissement ne devrait probablement pas être pris aussi au sérieux sur les CPU modernes dotés de la technologie Hyper-Threading avec la dernière version de VirtualBox. Une chose est sûre: ne me prenez pas pour le mot et testez-le dans vos propres conditions, avant de décider d'appliquer ce paramètre de manière permanente.

LinuxSecurityFreak
la source
L'avez-vous exécuté sur la même machine virtuelle avec les cœurs modifiés ou deux machines virtuelles différentes (mais identiques)? Si vous utilisez la même machine virtuelle, avez-vous essayé à nouveau dans l’ordre suivant d’exclure l’influence éventuelle des algorithmes de mise en cache du système d’exploitation invité?
Wildcard
Essayez de faire un test de gravure du processeur réel pour le plaisir.
cylgalad
Quelque chose comme prime95 pendant au moins une heure. Et essayez de naviguer sur le Web sur l'hôte en même temps. Comme je l'ai dit, c'est bien si vous ne faites rien sur l'hôte ou si vous n'exécutez pas plus d'un ordinateur virtuel à la fois. Si c'était aussi grave, la limite aurait été imposée dans Virtualbox au lieu d'un avertissement.
cylgalad
Une autre chose que vous pouvez essayer mais cela peut être plus difficile. Installez une machine gentoo ou Linux à partir de la machine virtuelle Scratch et vérifiez comment les choses se passent lors de la compilation intensive. Ou essayez de construire du chrome dans une machine virtuelle.
cylgalad
@Vlastimil totalement d'accord. Dans mon cas, j’utilise VM pour la compilation C ++ (qui est une tâche liée au processeur) et la seule raison pour laquelle j’ai eu un processeur à 16 cœurs était de pouvoir compiler plus rapidement. Cet avertissement est un non-sens complet sans explication appropriée et conduit à cette conclusion erronée telle que "Les choses pourraient en fait être plus rapides avec moins de processeurs dans la VM"
Pavel P
16

En tant que concepteur de système d'exploitation, je suis tout à fait d'accord avec le résultat des mesures. La quantité de conneries produites ailleurs sur le sujet est incroyable.

Voir le nombre de cœurs logiques comme le nombre de threads / processus parallèles pouvant être exécutés par le matériel. Cela est réalisé en dupliquant, par exemple, les registres et les pointeurs d’instructions d’un cœur de CPU. Le cœur de la CPU lui-même décide maintenant quel thread (pointeur d'instruction) utiliser. Il décidera d'utiliser l'autre thread car les instructions du thread actuel ne sont pas disponibles dans le cache et doivent être extraites, par exemple, de la mémoire ou du cache L3. Ce mécanisme créera une amélioration potentielle de 10% à 30% en instructions / secondes ou en performances du processeur.

Si vous exécutez une seule application avec un seul thread, vous ne pourrez pas profiter de cet avantage, mais si vous exécutez deux applications très chargées, par exemple sur un ancien Pentium HT, vous pourrez en tirer parti. Il en va de même pour les applications qui ont plusieurs threads. Mon système Linux a 200 threads, de sorte que certains avantages liés à la charge réelle sont toujours présents. Toutes ces remarques s'appliquent sans virtualisation.

Virtualbox limite uniquement le nombre de threads pouvant être exécutés en parallèle pour chaque machine virtuelle, mais le planificateur de processus hôte modifie le ou les processeurs logiques et donc le ou les processeurs physiques sur lesquels les processus de la VM s'exécutent de manière dynamique. Si vous exécutez des applications à forte charge sur une machine virtuelle, les cœurs logiques supplémentaires vous procureront le même avantage, à savoir 10% à 30%. La charge peut être une seule application multithread ou un ensemble d’applications différentes.

Sur les systèmes modernes avec VT-x ou AMD-V, il n’existe aucune pénalité en termes de performances pour limiter le nombre de cœurs logiques au maximum, puisqu’il n’existe pas non plus de pénalité en termes de performances pour l’exécution simultanée de plusieurs machines virtuelles. Votre limite étant la performance de votre puce de processeur, vous ne pouvez pas restituer des vidéos sur 3 ordinateurs virtuels en même temps sans ralentir chaque ordinateur virtuel, car ils doivent partager le même processeur physique.

Votre système hôte peut devenir irresponsable si vous restituez une vidéo sur une machine virtuelle avec tous les cœurs logiques présents, mais vous auriez presque le même problème si vous exécutiez cette application de rendu sur votre hôte. Au moins dans VM, vous avez le choix et vous pouvez le résoudre en limitant la charge maximale du processeur à 80% -90% ou en réduisant le nombre de cœurs pour cette raison.

Bert Nijhof
la source
0

Mon meilleur deux cents est de ne jamais utiliser tous les cœurs / threads, laissez juste un ou deux pour l'hôte.

Donc, dans votre cas, donnez à l’invité un noyau de six, jamais un noyau (car vous n’avez que 8 threads sur l’hôte).

Si le nombre de threads disponibles (à ne pas confondre avec les cœurs) sur l'hôte est:

  • Si <2, mieux vaut ne pas utiliser de machine virtuelle du tout
  • Si 2, utilisez des machines virtuelles en mode mono-core ou prenez un risque en utilisant un invité double coeur
  • Si> 2, mieux utiliser une formule

Pour plus de deux discussions, j'ai tendance à utiliser cette formule:

  • N = Nombre de threads pour l'hôte
  • M = Nombre de machines virtuelles simultanées que je veux exécuter (en supposant un équilibre égal, le même nombre de cœurs d'invités pour chaque invité)
  • Formula = (N-1) / M si l'hôte n'a que 4 threads ou moins
  • Formula = (N-2) / M si l'hôte a plus de 4 threads

Mon expérience me dit qu'il est beaucoup plus doux et moins risqué de ne pas dépasser cette limite de formule.

Avertissement: Il n’est pas permis de changer le nombre de cœurs d’invités lors de l’exécution de l’invité, mais il est permis de réduire l’utilisation du processeur de 100% à 75% ou 50%. L’invité peut échouer.

Donc, parfois, j'ai tendance à donner à deux invités 6 six cœurs sur un hôte à 8 threads (le nombre de la formule comme s'il n'y avait qu'un invité au lieu de deux), mais en les limitant à 50% de la vitesse du processeur (afin que les deux invités puissent utiliser 1 / 2 du temps de la CPU), mais seulement quand je sais que les invités vont exécuter des applications qui ont un rapport plus grand qu'un parallèle, comme avec image compare / joint, etc.

Laura
la source
1
Vous avez vous-même fait ces formules? Ou pouvez-vous ajouter des citations?
LinuxSecurityFreak