Hyper-V e Hyper-threading: ¿encendido o apagado?

Con las nuevas CPU Xeon compatibles con Hyper-threading, ¿cuál es la sabiduría actual con respecto al uso (o no) en una máquina host Hyper-V?

Originalmente tenía la impresión de que encenderlo en un entorno de host virtual podría ser perjudicial, ya que las CPU 'extra' no eran núcleos verdaderos. Sin embargo, también he leído (sin confirmar) comentarios en la línea de MS haciendo un trabajo duro para que Hyper-V funcione bien en un entorno Hyper-threading.

¿Alguien tiene alguna información sólida o experiencia al respecto? ¡Aclamaciones!

El viejo problema con Hyper-Threading en Virtual Server 2005, sin volverse demasiado técnico, es que la memoria caché de la CPU se estaba envenenando, es decir, no almacenaba casi nada porque los contextos de lo que estaba sucediendo en cada subproceso no estaban relacionados, lo que los hacía competir por el caché en chip.

Los chips más nuevos tienen cachés más grandes e inteligentes, por lo que esto no es un problema.

¿Es ideal tener encendido o apagado? Eso realmente depende de la carga de trabajo. Si ambos subprocesos ejecutan la misma máquina virtual y la misma tarea, entonces seguramente sería una GRAN ventaja tenerla activada. Si estuvieran haciendo cosas no relacionadas con una gran cantidad de E / S de RAM aleatorias (varias máquinas virtuales diferentes, por ejemplo), causaría que solo la mitad de la memoria caché del chip estuviera disponible para cada uno, lo que en teoría podría ser más lento. En realidad, rara vez lo es.

Si tiene chips de generaciones anteriores, es posible que desee verificar los tamaños de caché del chip: en la virtualización, el caché más grande puede mejorar. La RAM realmente es MUCHO más lenta que las CPU, simplemente no CERCA de tan mala como las unidades de disco.

NOTA: Lo que está leyendo que dice "apagar" se encontró con respecto a los chips que eran de un solo núcleo con Hyper-Threading - Por ejemplo, esta fue la respuesta oficial en el día (2005/2006) - http: //www.VirtualServerFAQ .com / tiki-index.php? page = VirtualServerHostDualCore

Steve Radich http://www.VirtualServerFAQ.com

Según Windows IT Pro, desea dejarlo encendido:

• John Savill, WindowsITPro.com, 2009-03-08, P. ¿Hyper-Threading afecta a Hyper-V? (Archivado aquí ).

R. El nuevo procesador Intel Core i7 de cuatro núcleos permite el subprocesamiento múltiple, que divide cada núcleo de procesador en dos núcleos virtuales para (potencialmente) mejorar el rendimiento.

La preocupación con Hyper-V y Hyper-Threading es que usted asigna un número de núcleos de procesador a cada máquina virtual (VM). Imagine que asigna un procesador cada uno a dos máquinas virtuales invitadas desde la consola de administración de Hyper-V, pensando que cada uno usará un núcleo separado. ¿Qué sucede si el hipervisor asigna cada una de las máquinas virtuales al mismo núcleo físico y cada una obtiene un núcleo virtual? Potencialmente obtendría un rendimiento pésimo y tres núcleos físicos no harían mucho, donde le hubiera gustado que cada VM obtuviera su propio núcleo físico.

Afortunadamente, este no es el caso. Microsoft ha trabajado mucho en Hyper-Threading e Hyper-V. Esencialmente, aunque Hyper-Threading ayudará a veces al rendimiento, nunca perjudicará el rendimiento, por lo que Hyper-Threading debería estar habilitado.

Los programas que son conscientes de hyperthreading pueden distinguir entre un núcleo físico y un núcleo lógico (virtual), y asignar recursos en consecuencia.

Hyperthreading disminuye el costo de cambio de contexto al permitir que los estados de dos procesos se almacenen en un momento dado, en lugar de solo un estado a la vez. El cambio de contexto generalmente se considera muy costoso, ya que debe cargar todo el estado de un proceso en la CPU. Esto significa que si tiene un proceso intensivo de CPU en ejecución, la CPU hiperprocesada con frecuencia puede cambiar entre ese proceso y otros sin incurrir en un gran impacto en el rendimiento.

La ventaja de ejecutar servidores virtuales es que puede crear un gran conjunto de recursos que pueden asignarse a diferentes servidores sobre la marcha, según sea necesario. Esto incluye reasignar núcleos de CPU y equilibrar la carga en todos los núcleos disponibles. Si el hipervisor no conoce la diferencia entre un núcleo físico y un núcleo lógico, entonces tiene razón: algunos núcleos físicos pueden permanecer inactivos mientras que otros están vinculados al 100% de utilización de la CPU, mientras que ambos núcleos lógicos compiten por la CPU hora. Sin embargo, si el hipervisor puede distinguir la diferencia entre los núcleos físicos y lógicos, intentará equilibrar la carga de la CPU en las CPU físicas antes de asignar múltiples procesos a dos núcleos lógicos que pertenecen al mismo núcleo físico.

No he estudiado el problema en detalle, pero Microsoft no recomienda usar hyperthreading con Exchange 2010 debido a problemas de "planificación y monitoreo de capacidad". Es posible que desee probar sus propias cargas de trabajo antes de elegir una configuración u otra.

Hyperthreading: ¡Guau, procesadores gratuitos!

Apágalo. Si bien las implementaciones modernas de subprocesamiento múltiple simultáneo (SMT), también conocido como hyperthreading, pueden mejorar absolutamente el rendimiento de la CPU para la mayoría de las aplicaciones, los beneficios de Exchange 2013 no superan los impactos negativos. Resulta que puede haber un impacto significativo en la utilización de la memoria en los servidores de Exchange cuando el hyperthreading está habilitado debido a la forma en que el recolector de basura del servidor .NET asigna montones. El recolector de basura del servidor observa el número total de procesadores lógicos cuando se inicia una aplicación y asigna un montón por procesador lógico. Esto significa que el uso de memoria en el inicio para uno de nuestros servicios que utilizan el recolector de basura del servidor será casi el doble con hyperthreading activado vs. cuando está desactivado. Este aumento significativo en la memoria, junto con un análisis del aumento real del rendimiento de la CPU para las cargas de trabajo de Exchange 2013 en las pruebas de laboratorio internas nos ha llevado a una recomendación de mejores prácticas de que se debe deshabilitar hyperthreading para todos los servidores de Exchange 2013. Los beneficios no superan el impacto negativo.

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