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

Question

Comme j'ai un processeur capable de Hyper-Threading , je me demande, est-ce une mauvaise idée d'attribuer plus de cœurs de processeur virtuels que le nombre de cœurs de processeur physiques comme le suggère l'avertissement suivant:

Transcription:

Plus de CPU virtuelles sont affectées à la machine virtuelle que le nombre de CPU physiques sur le système hôte. Cela risque de dégrader les performances de votre machine virtuelle. Veuillez envisager de réduire le nombre de CPU virtuels.

Quelqu'un peut-il raisonner sur ce sujet?

EDIT1:

Le CPU en question est Intel Core i7-4700HQ, Ark Intel , CPU Benchmark

EDIT2:

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

LinuxSecurityFreak · Accepted Answer

Matériel/OS/Logiciel

Host: Linux Mint 18 Cinnamon 64 bits (entièrement mis à jour); Version du noyau 4.4.0-47-générique

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

Processeur: Intel Core i7-4700HQ , (6 Mo de cache, 4 cœurs physiques ou 8 utilisant Hyper-Threading ), Benchmark CP

VirtualBox: Version 5.1.10 r112026 (Qt5.5.1)

Ajouts d'invités: Installé et à jour

Benchmark Tool # 1: WinRAR version 5.40 final 64 bits

Benchmark Tool # 2: VeraCrypt version 1.19 final 64 bits

Préparation

Dans les deux cas, j'ai attendu après le démarrage que le CPU, la RAM et le lecteur de disque soient stables près du point zéro.

Méthode

Clonage de la machine virtuelle d'origine pour en avoir deux identiques.
J'ai, pour la deuxième passe, depuis le redémarrage désactivé Antivirus indiqué au bas de cette réponse et mis à jour WinRAR dans les deux cas d'une version bêta à la version finale.
J'ai fait la même préparation que celle indiquée précédemment.
La machine virtuelle a fonctionné au premier plan, sans aucune autre application gourmande en temps CPU en cours d'exécution, j'ai désactivé ce que je pouvais pour que le test ne soit pas influencé.
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

4 cœurs => 7,5 minutes ( plus court le temps vaut mieux)

WinRAR avec 4 cœurs activés, 1,5 Go traités en 7,5 minutes.
8 noyaux => 4.5 minutes ( plus court le temps est meilleur)

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

VeraCrypt

4 noyaux => vitesse 2.6 Gio/s ( plus haut la vitesse est meilleure)

VeraCrypt avec 4 cœurs activés, AES accéléré par HW (AES-NI) vitesse 2.6 Gio/s.
8 noyaux => vitesse 3.9 Gio/s ( plus haut la vitesse est meilleure)

VeraCrypt avec 8 cœurs activés, AES accéléré par HW (AES-NI) vitesse 3.9 Gio/s.

Conclusion

Je pouvais exécuter autant de tests que nécessaire. Mais je pense que si ces deux-là, dont l'un est un test de compression plutôt complexe, le second étant un ensemble de tests de cryptage plutôt complexes, quel serait l'intérêt.

Les deux repères 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 eu lieu en RAM pour exclure le goulot d'étranglement d'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 êtes d'accord avec moi, que cet avertissement ne devrait probablement pas être pris si au sérieux sur les processeurs modernes avec Hyper-Threading avec la dernière version de VirtualBox. Une chose est sûre: ne me prenez pas pour le Word et testez-le dans vos propres conditions, avant de décider d'appliquer ce paramètre de façon permanente.

Nouvelle référence

Hôte + Invité: Linux Mint 19.2 "Tina" - Cannelle (64 bits) ; les deux avec le noyau: 5.3.0-24-generic.

Processeur: Intel® Core ™ i7-7700HQ ; 6 Mo de cache, jusqu'à 3,80 GHz, 4 cœurs physiques ou 8 utilisant l'hyper-threading, comparaison des benchmarks CP

VirtualBox: Version 6.1.0 r135406 (Qt5.9.5)

Ajouts d'invités: Installé et à jour

Benchmark Tool: VeraCrypt version 1.24 Hotfix1 64 bits final ( page Web , lien de téléchargement deb direct )

Préparation et méthode

Identique à la référence précédente.

Résultats

Cryptage VeraCrypt AES avec 4 cœurs

⟶ vitesse 4,8 Gio/s ^{(une vitesse plus élevée est meilleure)}

Cryptage VeraCrypt AES avec 8 cœurs ( Hyper-Threading avertissement émis)

⟶ vitesse 7,2 Gio/s ^{(une vitesse plus élevée est meilleure)}

Conclusion

Merveilleuse augmentation de 50% des performances avec Hyper-Threading activé, mais seulement avec l'AES malheureusement, je devrai exécuter un test plus complet. Sera de retour dans quelques jours avec des résultats.

Bert Nijhof · Answer

En tant que concepteur d'OS, je suis entièrement 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 qui peuvent être exécutés par le HW. Ceci est réalisé en dupliquant par exemple les registres et pointeurs d'instructions d'un cœur de CPU. Le cœur du processeur lui-même décide maintenant quel thread (pointeur d'instruction) utiliser. Il décidera d'utiliser l'autre thread car l'instruction du thread actuel n'est pas disponible dans le cache et doit être récupérée par ex. mémoire ou cache L3. Ce mécanisme créera une amélioration potentielle de 10% à 30% des instructions/secondes ou des 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 à charge élevée sur, par exemple, un ancien HT Pentium, vous pourrez en profiter. Il en va de même bien sûr pour les applications, qui ont plus d'un thread. Mon système Linux a 200 threads, donc certains avantages dépendant de la charge réelle sont toujours présents. Toutes ces remarques s'appliquent sans virtualisation.

Virtualbox limite uniquement le nombre de threads pouvant s'exécuter en parallèle pour chaque machine virtuelle (VM), mais le planificateur de processus hôte changera le ou les processeurs logiques et donc les processeurs physiques, sur lesquels le VM s'exécutent de manière dynamique. Si vous exécutez une application à charge élevée sur une machine virtuelle, les cœurs logiques supplémentaires vous offriront le même avantage de 10% à 30%. La charge peut être une application multithread unique ou un ensemble de différentes applications.

Sur les systèmes modernes avec VT-x ou AMD-V, il n'y a pas de pénalité de performance pour maximiser le nombre de cœurs logiques, car il n'y a pas non plus de pénalité de performance notable pour exécuter plus de machines virtuelles en même temps. Votre limite est la performance de votre puce CPU, vous ne pouvez donc pas rendre des vidéos sur 3 VM en même temps sans ralentir chaque VM, car elles doivent partager le même CPU physique.

Votre système hôte peut devenir irresponsable si vous restituez une vidéo sur un VM 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 CPU maximale à 80% -90% ou en réduisant le nombre de cœurs pour cette raison.

Laura · Answer

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

Donc, dans votre cas, donnez à l'invité un six cœurs, jamais un huitième (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 machines virtuelles du tout
Si 2, utilisez des machines virtuelles en mode mono-core ou prenez un risque et utilisez un invité dual core
Si> 2, mieux utiliser une formule

Pour plus de deux fils, 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, même nombre de cœurs invités pour chaque invité)
Formule = (N-1)/M si l'hôte n'a que 4 threads ou moins
Formule = (N-2)/M si l'hôte a plus de 4 threads

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

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

Donc, parfois, j'ai tendance à donner à deux invités 6 six cœurs sur un hôte à 8 threads (le numéro de la formule comme si un seul invité au lieu de deux invités), mais en les limitant à 50% de la vitesse du processeur (pour que les deux invités puissent utiliser 1/2 du temps CPU), mais seulement quand je sais que les invités exécuteront des applications qui ont un rapport parallèle plus grand, comme avec la comparaison/joint d'image, etc.