sql-server – ¿Conocimientos actuales sobre SQL Server y Hyperthreading?

Pregunta:

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

Este problema se está volviendo gradualmente menos relevante a medida que los verdaderos procesadores de múltiples núcleos reemplazan a los de hiperproceso, 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 de ensayo, pero ¿qué pasa con los servidores que ya han entrado en producción con HT habilitado? ¿Cómo puedo saber si los problemas de rendimiento que estamos experimentando pueden estar relacionados con HT? ¿Existe alguna combinación específica de contadores perfmon que pueda apuntarme en esa dirección, a diferencia de 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 mejora a través de la junta 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 solución de problemas de rendimiento convencional está en curso, pero a veces un poco ayuda.

Respuesta:

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

Al comprender ese trasfondo, el 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 el hyperthreading y puede resultar en esperas altas de CXPACKET ya que SQLOS puede intentar ejecutar una consulta en DOP 8 en lo que en realidad es un sistema DOP 4. Si el uso de su CPU es bajo, es posible que no lo note, pero cuanto mayor sea el uso de su CPU, más problemático podría volverse. Recientemente tuve una discusión en Twitter sobre esto, y el consenso fue "Depende" en cuanto a si ayudaría o perjudicaría o no.

Si tiene muchas esperas de señal en su servidor, pero tiene un bajo uso de CPU, puede ver beneficios al habilitar el hyperthreading, lo que duplicará sus programadores internos y distribuirá más a los trabajadores, lo que significa que no esperarán para ejecutarse en la cola ejecutable. tanto tiempo. Sin embargo, si su carga de trabajo utilizó mucho el paralelismo, obtiene grandes esperas de CXPACKET en sys.dm_os_wait_stats, podría considerar deshabilitar el hyperthreading para ver si reduce sus esperas.

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım