Sabiduría actual sobre SQL Server y Hyperthreading?

Muchos artículos (consulte el artículo original de SQL 2000 de Slava Oks y la actualización de SQL 2005 de Kevin Kline ) recomiendan deshabilitar hyperthreading en servidores SQL, o al menos probar su carga de trabajo específica antes de habilitarla en sus servidores.

Este problema se está volviendo gradualmente menos relevante a medida que los verdaderos procesadores multinúcleo reemplazan a los hiperprocesados, pero ¿cuál es la sabiduría actual sobre este tema? ¿Este consejo cambia alguno con SQL 2005 de 64 bits, SQL 2008 o Windows Server 2008?

Idealmente, esto debería probarse por adelantado en un entorno provisional, pero ¿qué pasa con los servidores que ya han llegado a producción con HT habilitado? ¿Cómo puedo saber si los problemas de rendimiento que estamos experimentando podrían estar relacionados con HT? ¿Existe alguna combinación específica de contadores de perfmon que pueda apuntarme en esa dirección, en oposición a todas las otras cosas que normalmente persigo cuando trabajo para mejorar el rendimiento de SQL?

Editar : Esto es especialmente atractivo debido a la posibilidad de una en todos los ámbitos de mejora para algunos de mis servidores de alto rendimiento de la CPU, pero el cliente va a querer ver algo concreto que me ayuda a identificar qué servidores realmente podrían beneficiarse de deshabilitar hyperthreading. Por supuesto, la resolución de problemas de rendimiento convencional está en curso, pero a veces ayuda un poco.

En el SQLOS se crea un planificador para cada procesador lógico que ve SQL Server. Con hyperthreading habilitado, esto equivale a duplicar los planificadores. Uno de los propósitos de SQLOS es minimizar y evitar que ocurra un cambio de contexto, por lo que solo se crea un planificador para cada procesador lógico. Una vez que SQLOS crea los planificadores, el número total de trabajadores se divide entre los planificadores. El SQLOS implementa una forma de programación cooperativa en la que los trabajadores producen el planificador ya que requiere recursos no disponibles, o alcanza su cantidad de ejecución permitiendo que otros trabajadores se ejecuten en el planificador. Esto mantiene el cambio de contexto al mínimo ya que el planificador está haciendo el trabajo y están vinculados uno por uno.

Entendiendo ese trasfondo, hyperthreading funciona de manera opuesta a cómo SQLOS está específicamente diseñado para funcionar. Específicamente, el paralelismo puede ser problemático con hyperthreading y puede dar lugar a altas esperas de CXPACKET ya que SQLOS puede intentar ejecutar una consulta en DOP 8 sobre qué es realmente un sistema DOP 4. Si la utilización de su CPU es baja, es posible que no se dé cuenta, pero cuanto mayor sea la utilización de la CPU, más problemática podría ser. Recientemente tuve una discusión en Twitter con respecto a esto, y el consenso fue "Depende" en cuanto a si ayudaría o no.

Si tiene muchas señales en espera en su servidor, pero tiene una baja utilización de la CPU, es posible que vea un beneficio que permite el hyperthreading que duplicará sus programadores internos y extenderá más a los trabajadores, lo que significa que no esperarán para ejecutarse en la cola ejecutable tan largo Sin embargo, si su carga de trabajo utiliza el paralelismo en gran medida, obtiene grandes esperas de CXPACKET en sys.dm_os_wait_stats, puede deshabilitar hyperthreading para ver si reduce sus esperas.

En realidad, el hyperthreading no ha desaparecido, los nuevos chips Nehalem de cuatro núcleos de Intel tienen hyperthreading. En cuanto a si se recomienda o no, "depende" como siempre, cada situación es probablemente diferente.

Es poco probable que la HT sea la causa principal de cualquier problema de rendimiento, pero sin más detalles, es difícil decir cuál es. Realice algunas sesiones de rendimiento, con frecuencias de muestreo bastante largas, como una vez cada 30-60 segundos, y obteniendo CPU, longitud de la cola del disco en los discos de datos y registros, la expectativa de vida de la página es una buena medida de si tiene suficiente memoria. Si tiene más del 80% de CPU, o si las colas de disco están en los tres dígitos, encontró su problema.

SQL Server 2000 en un HP DL360 G3:

Ejecuté un informe seis veces y tiré la carrera inicial y grabé las últimas cinco. Luego reinicié la base de datos nuevamente y volví a activar Hyperthreading. Ejecuté el informe seis veces más, conservando los datos de las últimas cinco ejecuciones.

Observaciones:

• Desactivar Hyperthreading no cuesta 2 veces el uso aparente de la CPU, solo alrededor de 1.5 veces.
• Desactivar Hyperthreading hace que un informe aleatorio de larga duración se ejecute un 5,2% más rápido (en promedio).

Ejecuciones repetidas del informe:

Con Hyperthreading: 20.95%, 21.1%, 21.9%, 20.8%, 20.5%
Tiempos de ejecución en ms: 20282, 21141, 20188, 22297, 25282. Promedio 21838

Sin Hyperthreading: 29.4%, 28.2%, 29.1%, 28.2%, 27.1%
Tiempos de ejecución en ms: 20125, 20156, 19937, 21656, 21656. Promedio 20706