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:

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.

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, 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, 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 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 à 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.

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.

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.