Hyper-V et Hyper-threading: activé ou désactivé?

Avec les nouveaux processeurs Xeon prenant en charge l'hyper-threading, quelle est la sagesse actuelle en ce qui concerne son utilisation (ou non) sur une machine hôte Hyper-V?

J'avais à l'origine l'impression que l'activer dans un environnement d'hôte virtuel pouvait être préjudiciable car les CPU «supplémentaires» n'étaient pas de vrais cœurs. Cependant, j'ai également lu des commentaires (non confirmés) dans le sens de MS faisant un travail difficile pour que Hyper-V fonctionne correctement dans un environnement Hyper-threading.

Quelqu'un possède-t-il des informations ou une expérience solides à cet égard? À votre santé!

Le vieux problème avec Hyper-Threading dans Virtual Server 2005, sans devenir trop technique, est que le cache du processeur était empoisonné, c'est-à-dire qu'il ne mettait en cache presque rien car les contextes de ce qui se passait sur chaque thread n'étaient pas liés - les obligeant à rivaliser pour le cache sur puce.

Les puces plus récentes ont des caches plus grands et plus intelligents, donc c'est moins un problème.

Est-il idéal d'avoir ou de désactiver? Cela dépend vraiment de la charge de travail. Si les deux threads exécutent la même machine virtuelle et la même tâche, ce serait presque certainement un GRAND avantage d'avoir. S'ils faisaient des choses indépendantes avec beaucoup d'E / S RAM aléatoires (plusieurs machines virtuelles différentes par exemple), cela ne ferait que mettre à disposition de la moitié du cache de la puce - ce qui en théorie pourrait être plus lent - En réalité, cela ne l'est rarement plus.

Si vous avez des puces de génération plus ancienne, vous voudrez peut-être vérifier la taille du cache de puces: dans la virtualisation, le cache le plus volumineux est le meilleur. La RAM est vraiment beaucoup plus lente que les processeurs - tout simplement pas aussi mauvais que les lecteurs de disque.

REMARQUE: ce que vous lisez qui dit "désactiver" a été trouvé concernant les puces qui étaient à noyau unique avec Hyper-Threading - Par exemple, c'était une réponse officielle à l'époque (2005/2006?) - http: //www.VirtualServerFAQ .com / tiki-index.php? page = VirtualServerHostDualCore

Steve Radich http://www.VirtualServerFAQ.com

Selon Windows IT Pro, vous souhaitez le laisser sur:

• John Savill, WindowsITPro.com, 2009-03-08, Q. L'hyper-threading affecte-t-il Hyper-V? (Archivé ici .)

A. Le nouveau processeur Intel Core i7 à quatre cœurs permet l'hyper-threading, qui divise chaque cœur de processeur en deux cœurs virtuels pour (potentiellement) améliorer les performances.

Le problème avec Hyper-V et l'hyper-threading est que vous affectez un certain nombre de cœurs de processeur à chaque machine virtuelle (VM). Imaginez que vous affectez un processeur chacun à deux machines virtuelles invitées à partir de la console de gestion Hyper-V, en pensant que chacune va utiliser un cœur distinct. Que se passe-t-il si l'hyperviseur attribue chacune des machines virtuelles au même cœur physique, chacune obtenant un cœur virtuel? Vous obtiendrez potentiellement des performances médiocres et trois cœurs physiques ne faisant pas grand-chose, où vous auriez aimé que chaque machine virtuelle ait son propre cœur physique.

Heureusement, ce n'est pas le cas. Microsoft a beaucoup travaillé sur Hyper-Threading et Hyper-V. Essentiellement, bien que l'hyper-threading améliore parfois les performances, il ne nuira jamais aux performances, donc l'hyper-threading doit être activé.

Les programmes qui connaissent l'hyperthreading sont capables de faire la distinction entre un noyau physique et un noyau logique (virtuel) et d'allouer les ressources en conséquence.

L'hyperthreading diminue le coût de la commutation de contexte en permettant aux états de deux processus d'être stockés à un moment donné, au lieu d'un seul état à la fois. La commutation de contexte est généralement considérée comme très coûteuse, car vous devez charger l'intégralité de l'état d'un processus dans le processeur. Cela signifie que si vous avez un processus gourmand en CPU en cours d'exécution, le CPU hyperthreadé peut fréquemment basculer entre ce processus et d'autres sans encourir une perte de performances importante.

L'avantage de l'exécution de serveurs virtuels est que vous pouvez créer un grand pool de ressources qui peuvent être allouées à différents serveurs à la volée, selon les besoins. Cela comprend la réaffectation des cœurs de processeur et l'équilibrage de la charge sur tous les cœurs disponibles. Si l'hyperviseur ne connaît pas la différence entre un cœur physique et un cœur logique, alors vous avez raison - certains cœurs physiques peuvent rester inactifs tandis que d'autres sont indexés à 100% d'utilisation du processeur tandis que leurs deux cœurs logiques sont en concurrence pour le processeur temps. Cependant, si l'hyperviseur est capable de faire la différence entre les cœurs physiques et logiques, il essaiera d'équilibrer la charge du processeur sur les processeurs physiques avant d'allouer plusieurs processus à deux cœurs logiques qui appartiennent au même cœur physique.

Je n'ai pas étudié le problème en détail, mais Microsoft ne recommande pas d'utiliser l'hyperthreading avec Exchange 2010 en raison de problèmes de "planification et de surveillance des capacités". Vous voudrez peut-être tester vos propres charges de travail avant de choisir une configuration ou l'autre.

Hyperthreading: Wow, processeurs gratuits!

Éteignez-le. Alors que les implémentations modernes du multithreading simultané (SMT), également connues sous le nom d'hyperthreading, peuvent absolument améliorer le débit du processeur pour la plupart des applications, les avantages d'Exchange 2013 ne l'emportent pas sur les impacts négatifs. Il s'avère qu'il peut y avoir un impact significatif sur l'utilisation de la mémoire sur les serveurs Exchange lorsque l'hyperthreading est activé en raison de la façon dont le garbage collector du serveur .NET alloue les tas. Le garbage collector du serveur examine le nombre total de processeurs logiques au démarrage d'une application et alloue un segment par processeur logique. Cela signifie que l'utilisation de la mémoire au démarrage pour l'un de nos services utilisant le garbage collector du serveur sera presque doublée avec l'hyperthreading activé par rapport à sa désactivation. Cette augmentation significative de la mémoire, ainsi qu'une analyse de l'augmentation réelle du débit du processeur pour les charges de travail Exchange 2013 dans les tests de laboratoire internes nous ont conduit à une recommandation de meilleures pratiques selon laquelle l'hyperthreading doit être désactivé pour tous les serveurs Exchange 2013. Les avantages ne l'emportent pas sur l'impact négatif.

Copié depuis: http://blogs.technet.com/b/exchange/archive/2013/05/06/ask-the-perf-guy-sizing-exchange-2013-deployments.aspx