La desactivación de hyperthreading mejorará el rendimiento en nuestra instalación de SQL Server

28

Relacionado con: Conocimiento actual sobre SQL Server y Hyperthreading

Recientemente actualizamos nuestro servidor de base de datos Windows 2008 R2 de un X5470 a un X5560 . La teoría es que ambas CPU tienen un rendimiento muy similar, en todo caso, el X5560 es ligeramente más rápido.

Sin embargo, el rendimiento de SQL Server 2008 R2 ha sido bastante malo durante el último día y el uso de la CPU ha sido bastante alto.

La expectativa de vida de la página es enorme, estamos obteniendo casi el 100% de aciertos de caché para las páginas, por lo que la memoria no es un problema.

Cuando corrí:

SELECT * FROM sys.dm_os_wait_stats 
order by signal_wait_time_ms desc

Tengo:

wait_type waiting_tasks_count wait_time_ms max_wait_time_ms signal_wait_time_ms
-------------------------------------------------- ---------- -------------------- -------------------- -------------------- --------------------
XE_TIMER_EVENT 115166 2799125790 30165 2799125065
REQUEST_FOR_DEADLOCK_SEARCH 559393 2799053973 5180 2799053973
SOS_SCHEDULER_YIELD 152289883 189948844 960 189756877
CXPACKET 234638389 2383701040 141334 118796827
SLEEP_TASK 170743505 1525669557 1406 76485386
LATCH_EX 97301008 810738519 1107 55093884
LOGMGR_QUEUE 16525384 2798527632 20751319 4083713
WRITELOG 16850119 18328365 1193 2367880
PAGELATCH_EX 13254618 8524515 11263 1670113
ASYNC_NETWORK_IO 23954146 6981220 7110 1475699

(10 filas afectadas)

Yo tambien corri

-- Isolate top waits for server instance since last restart or statistics clear
WITH Waits AS (
   SELECT 
        wait_type, 
        wait_time_ms / 1000. AS [wait_time_s],
        100. * wait_time_ms / SUM(wait_time_ms) OVER() AS [pct],
        ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS [rn]
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN ('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE',
    'SLEEP_TASK','SLEEP_SYSTEMTASK','SQLTRACE_BUFFER_FLUSH','WAITFOR','LOGMGR_QUEUE',
    'CHECKPOINT_QUEUE','REQUEST_FOR_DEADLOCK_SEARCH','XE_TIMER_EVENT','BROKER_TO_FLUSH',
    'BROKER_TASK_STOP','CLR_MANUAL_EVENT','CLR_AUTO_EVENT','DISPATCHER_QUEUE_SEMAPHORE',
    'FT_IFTS_SCHEDULER_IDLE_WAIT','XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN'))

SELECT W1.wait_type, 
    CAST(W1.wait_time_s AS DECIMAL(12, 2)) AS wait_time_s,
    CAST(W1.pct AS DECIMAL(12, 2)) AS pct,
    CAST(SUM(W2.pct) AS DECIMAL(12, 2)) AS running_pct
FROM Waits AS W1
INNER JOIN Waits AS W2 ON W2.rn <= W1.rn
GROUP BY W1.rn, W1.wait_type, W1.wait_time_s, W1.pct
HAVING SUM(W2.pct) - W1.pct < 95; -- percentage threshold

Y consiguió

wait_type wait_time_s pct running_pct
CXPACKET 554821.66 65.82 65.82
LATCH_EX 184123.16 21.84 87.66
SOS_SCHEDULER_YIELD 37541.17 4.45 92.11
PAGEIOLATCH_SH 19018.53 2.26 94.37
FT_IFTSHC_MUTEX 14306.05 1.70 96.07

Eso muestra enormes cantidades de tiempo sincronizando consultas que involucran paralelismo (alto CXPACKET). Además, anecdóticamente, muchas de estas consultas problemáticas se ejecutan en múltiples núcleos (no tenemos sugerencias de MAXDOP en ningún lugar de nuestro código)

El servidor no ha estado bajo carga durante más de un día más o menos. Estamos experimentando una gran variación con las ejecuciones de consultas, por lo general, muchas consultas parecen ser más lentas que en nuestro servidor de base de datos anterior y la CPU es realmente alta.

¿Deshabilitar Hyperthreading ayudará a reducir el uso de nuestra CPU y aumentar el rendimiento?

Sam Azafrán
fuente
Tenga en cuenta que CXPACKET no significa que haya mucho tiempo esperando que los procesos se fusionen. CXPACKET significa que el hilo está esperando que otro hilo termine su procesamiento. Debe mirar una consulta específica que tiene un hilo en la espera de CXPACKET y ver qué otros hilos están esperando además de CXPACKET. Suele ser IO o red. En la salida anterior, está esperando los pestillos y está siendo reprogramado. Alguna consulta necesita ser ajustada, o necesita ver por qué se están tomando los pestillos.
mrdenny
En nuestro caso, CXPACKET era alto ya que los otros subprocesos solo leían en exceso de la memoria caché (20 millones de lecturas lógicas por consulta). Nuestro caso, nuevamente, fue un anti-semiunión malo con una mesa particionada que solo tenía 700K filas.
ozamora
@mrdenny, sí, el tiempo de espera de alto bloqueo es preocupante, lo estamos investigando en este momento.
Sam Saffron

Respuestas:

10

Todavía siento que probar su carga de trabajo específica , según la respuesta original, es la única forma de estar seguro. No es una respuesta ideal cuando intentas ajustar un sistema de producción (por lo que preguntaría si fue posible obtener un banco de pruebas idéntico en sistemas donde el rendimiento y la disponibilidad realmente importan), pero es el único con el que estoy realmente cómodo. con.

Podemos hablar sobre la teoría de si Hyperthreading debería dañar o mejorar las cosas en general (creo que es más probable que dañe que la ayuda en los servidores, por lo que para una implementación "genérica" ​​probablemente lo deshabilitaría), pero hay solo hay una manera de ver con certeza si va a hacer una diferencia en su caso específico, y es probarlo y ver.

Rob Moir
fuente
3
Tenga en cuenta que no voté en contra, necesitamos toda la ayuda que podamos obtener, sin embargo, nos gustaría evitar puñaladas en la oscuridad en un sistema de producción. Quiero asegurarme de que reunimos suficientes diagnósticos antes de hacer la llamada para jugar con esta configuración.
Sam Saffron
3
Estoy seguro de que desea evitar 'jugar' con un sistema de producción, en un mundo ideal todos tendríamos entornos de prueba idénticos a la producción por ese motivo. Estoy de acuerdo con no querer cambiar la producción en especular. Sin embargo, mantengo mi respuesta: probar cargas de trabajo específicas es una parte importante de cualquier implementación y cualquiera que le diga lo contrario es un charlatán. Para mí, todas las señales apuntan a que el hipertronteo es un problema aquí, pero podemos hablar de cosas todo el día y toda la noche y todavía habrá una única forma de saberlo con certeza.
Rob Moir
55
Vota aquí: estoy de acuerdo con la respuesta. La respuesta general es: desactivar Hyperthreading. La respuesta más específica es: depende de los detalles y DEBE SER PROBADO.
TomTom
1
Por extraño que parezca, creo que esta es la mejor respuesta para aceptar, jugar con la configuración de maxdop puede causar muchos problemas, los cpus de Nehalem son mucho más rápidos que los xeones basados ​​en el núcleo, incluso a velocidades de reloj ligeramente más lentas, encuentro los argumentos en caché l2 un poco de un arenque rojo porque el caché l3 es mucho más grande. Como un apéndice vea: blog.stackoverflow.com/2010/10/database-upgrade , si alguien está viendo más del 20% de éxito / ganancia ... probablemente no se deba a HT.
Sam Saffron
He tenido la experiencia opuesta a @TomTom y @Robert. He descubierto que la activación de HT suele ser un 10-15% mejor que la desactivada. La ocasión en que apagarlo mejora el rendimiento ha sido rara.
Brian Knoblauch
12

Estoy de acuerdo que

  • en el mejor de los casos, la recomendación es "pruebe HyperThreading en su carga de trabajo y vea qué sucede". Estamos haciendo esto ahora mientras escribo, y ... ¡no es bueno!
  • probablemente debería comenzar siempre con HyperThreading deshabilitado, ya que es lo más seguro

Parece que deberíamos ajustar dos cosas:

  1. MAXDOP (Grados máximos de paralelismo). Todo lo que leo indica que tener esto sin límites es probablemente una mala idea, y la documentación de Microsoft dice:

    Establecer esta opción [MAXDOP] en ​​un valor mayor [que 8] a menudo causa el consumo de recursos no deseados y la degradación del rendimiento.

    algo más alto de 8lo que generalmente no se recomienda ... así que lo configuré 4por ahora. Fue cero (ilimitado) inicialmente.

  2. Umbral de costo para paralelismo. Aparentemente, el valor predeterminado de 5aquí se considera un valor predeterminado bastante bajo de acuerdo con algunas publicaciones de MVP de SQL que he encontrado; podemos ajustarlo para reducir la cantidad de paralelismo que incluso intenta el planificador.

Pero, sinceramente, se sienten como soluciones alternativas; Creo que la verdadera solución para nuestra carga de trabajo (índice de texto completo pesado) es deshabilitar HT.

Jeff Atwood
fuente
44
MAXDOP también causa problemas con HT, ya que podría intentar ejecutar dos subprocesos en la misma CPU si tiene, por ejemplo, 8 núcleos y 16 subprocesos, y su maxdop está configurado en 10. Generalmente, 1 MAXDOP por procesador lógico debería ser el máximo. Y ejecutar dos subprocesos en la misma CPU para el mismo proceso no tiene sentido.
Mark Henderson
2
@Farseeker eso solo sucede si no tienes un sistema operativo compatible con HyperThreading. Windows más reciente que 2000 lo sabe.
Mircea Chirea
Vale la pena señalar que estas anulaciones de maxdop solo estaban causando problemas. por defecto estuvo bien para nosotros
Sam Saffron
2
La versión estándar de SQL Server alcanza el máximo en MAXDOP de 4 de todos modos cuando se deja sin límites. Necesito Enterprise para ir más alto que eso. Hemos tenido algunas cargas de trabajo que han ido más rápido con MAXDOP de 1 (caja no HT, ejecutando múltiples AMD de 8 núcleos) ...
Brian Knoblauch
1
@Brian Knoblauch: sé esto más de un año después, pero me encontré con esta "versión estándar de SQL Server con un máximo de MAXDOP de 4 de todos modos cuando no se acota", cualquier posibilidad de que pueda señalarme hacia alguna documentación. Actualmente estamos hablando de usar MAXDOP en el trabajo, pero no estamos seguros de en qué configurarlo. ¿Esto significa básicamente que 4 es lo mismo que sin consolidar correcto?
Jeremy A. West
9

Anandtech descubrió que con la carga de lectura pura, dolía un poco, y con una carga pesada de escritura, era un poco una victoria. No he visto nada que me haga pensar que te dará un golpe mucho peor que -5%, o una victoria mucho mejor que 15%. Tenga en cuenta que con un Atom, es una gran victoria, pero esa es una CPU muy extraña.

Todo lo que cambiaste fue la CPU? Pasó de 12 MB de caché y 4 subprocesos, por lo que 3 MB de caché por subproceso, a 8 MB de caché y 8 subprocesos, por lo que 1 MB por subproceso. Ahora, eso es simplificar demasiado, pero apuesto a que eso es lo que te está matando, solías ejecutar consultas en caché y ahora las ejecutas desde RAM porque necesitan más de 1 MB pero menos de 3 MB. Apagar HT probablemente ayudará, pero volvería a la CPU anterior. Apague HT y obtendrá 2 MB por subproceso, pero si su carga de trabajo se agita con eso, no ayudará. Es muy posible que la antigua CPU de caché de 12 MB sea mucho más rápida para su carga de trabajo.

Intentaría desactivar HT y ver si eso es una mejora, pero sospecho que el caché es el rey para su carga de trabajo, y es posible que deba volver al chip de 12 MB.

Ronald Pottol
fuente
3
La observación de caché L2 por núcleo es una simplificación excesiva masiva , ya que la CPU está una generación completa por delante (Nehalem / Core i7 vs Core 2 Quad class).
Jeff Atwood
@Jess, @Ronald y Nehalem tienen poca caché L2. El grueso es L3, que se comparte entre núcleos.
Mircea Chirea
7

Hyperthreading es, en el mejor de los casos, solo una forma de abstraer la tarea de cambiar del sistema operativo y colocarla en el troquel, con acceso directo a la caché L1 y L2, lo que hace que la tarea de cambiar una carga sea más rápida.

Las pruebas con VMWare han indicado que deshabilitar HT no hizo una diferencia perceptible bajo carga estándar, y un aumento del 5% bajo carga pesada, debido al hecho de que ESXi es lo suficientemente inteligente como para saber la diferencia entre el hilo "real" y el hilo "falso" (hay mucho más que eso, pero eso es en términos simples). SQL Server 2005 no es tan inteligente, pero combinado con un sistema operativo actualizado debería haber pocas ventajas al deshabilitar HT.

Dicho todo esto, estoy de acuerdo con Ronald en que lo más probable es que sea tu caché L2. Una caída del 33% en el tamaño de la memoria caché es sustancial, y cuando especificamos nuestros servidores SQL siempre buscamos memoria caché por encima de la velocidad de reloj sin procesar.

Mark Henderson
fuente
¿Puede establecer afinidad externamente para que SQL ignore los 4 núcleos correctos?
Sam Saffron
3
En general, establecería afinidad entre los hilos de la CPU, pero siempre que MAXDOP esté configurado correctamente, no veo ninguna razón para establecer afinidad. Con HT, aunque el primer subproceso en ser golpeado en una CPU se convierte en el subproceso "principal", y el segundo subproceso es el subproceso "HT". Sin embargo, no hay subprocesos "principales" y "ht" reales, porque es el que haya llegado primero, y luego cuando cambian de tarea, el orden se invierte.
Mark Henderson
Las CPU basadas en Nehalem tienen MUY, MUY POCO caché L2, la mayoría de ellas L3 compartidas.
Mircea Chirea
7

Según mi experiencia, HT estaba haciendo que las operaciones de E / S tomaran para siempre mis nodos activos en un clúster de Windows 2008 R2 (ejecutando SQL Server 2008 R2). Un hecho interesante fue que no se reflejó en las estadísticas de espera ni en el pssdiag que ejecuté para el soporte de Microsoft.

La forma en que noté baja E / S fue simplemente mirando los contadores del sistema operativo para el disco físico. Como Sam señaló, escribí sobre esto aquí y aquí

Si NO experimenta problemas de E / S y está vinculado a la CPU, le sugiero que comience de esta manera:

Identifique qué procesos y bloques T-SQL están causando la mayor utilización de la CPU. En nuestra experiencia, después de solucionar el problema con E / S (al desactivar HT) identificamos el código que funcionaba horriblemente en 2008 R2 y funcionaba bien en 2005. Escribí sobre esto aquí .

Mientras está bajo una carga alta, ejecute sp_whoisactive de Adam Machanic. Puedes descargarlo desde aquí . Estábamos experimentando una utilización de CPU muy alta debido a la cantidad excesiva de lecturas lógicas (20 millones por consulta) debido a un plan realmente malo. Nuestros procesos estaban realizando anti-semi-combinaciones con tablas que fueron particionadas.

Mi próxima recomendación es ejecutar el generador de perfiles para identificar un conjunto de código T-SQL que tenga altas lecturas lógicas de CPU y E / S.

Con los pasos anteriores pudimos ajustar los procesos ofensivos y pasar del 85% de utilización sostenida de la CPU a casi nulo.

Buena suerte y no dude en enviarme un mensaje si encuentra una solución, ya que me gustaría agregar el caso a mi blog.

Gracias

Oscar

ozamora
fuente
1
+1 para el generador de perfiles, me salvó muchas veces una vez que se identificó un punto problemático
Mark Henderson
+1 gracias por todas sus sugerencias, ajustar nuestro SQL a un nivel razonable es una pesadilla total, dependemos en gran medida del texto completo para nuestro trato con las etiquetas, a menudo estamos buscando listas de elementos en etiquetas particulares, por lo que tomamos todo configurar y filtrar hacia abajo. Por ejemplo, obtener una lista de preguntas con las etiquetas [x] e [y] ordenadas por fecha implica extraer cantidades masivas de datos del texto completo y luego una unión masiva.
Sam Saffron
Entendido. Tome una muestra y ejecútela con estadísticas IO ON y vea si puede identificar cualquier tabla con las lecturas más lógicas. Una vez más, estábamos bien en 2005 y realmente mal en 2008 R2. Si solo encuentra una alta utilización de la CPU y tiene una alta espera CXPACKET, intente primero aumentando el Umbral de costo para el paralelismo a 10, 15 o incluso 20.
ozamora
Si nada más ayuda, desconecta la base de datos, apaga HT y ve desde allí. Buena suerte
ozamora
sp_whoisactive es una herramienta bastante impresionante, me encanta la forma en que se puede hacer clic en las consultas
Sam Saffron
2

Es difícil determinar si HT es bueno o malo.

Realmente depende del patrón de carga del servidor basado en la experiencia y la lectura. Es decir, cuando afecta el rendimiento, lo hace muy mal : de lo contrario, no lo notará.

La teoría que leí fue que los hilos comparten caché, lo que significa que en condiciones adversas cada hilo puede sobrescribir el caché del otro hilo. Si no tiene mucho paralelismo, o su carga es muchas consultas cortas, entonces puede que no le afecte.

He intentado con MAXDOP y la afinidad del procesador (en mi último rol real de DBA en SQL Server 2000) pero nunca pude encontrar nada concluyente: pero solo para mi tienda en ese momento.

Como prueba rápida, puede configurar la afinidad del procesador para usar solo núcleos físicos (los números más bajos) y ver qué sucede.

Sin embargo, a lo sumo pierde la mitad de sus núcleos. Hoy en día eso puede no importar en comparación con lo que estaba jugando hace unos años cuando era 2 vs 4 o 4 vs 8. Ahora es 8 vs 16 o 16 vs 32.

Editar: Una prueba de Slava Oks

gbn
fuente
¿Son los núcleos 0-3 físicos y 4-7 lógicos? ¿Así es como funciona? No podríamos decir, y yo no pudimos averiguar cualquier herramienta que me permita saber ..
Jeff Atwood
2
@ Jeff Atwood: Encontraré más más tarde. Lo he leído en alguna parte ... Por ahora: support.microsoft.com/kb/322385
gbn
Ese artículo de KB lo resume bastante.
pauska
Aunque ese artículo de KB contiene información útil, no parece responder directamente a la pregunta de Jeff sobre cómo se asignan exactamente los procesadores lógicos a los físicos. Mi cerebro se frió a la mitad, pero espero que este artículo de INTEL le brinde lo que necesita para resolver el mapeo: software.intel.com/en-us/articles/… también vea software.intel.com/en-us/ blogs / 2009/12/21 / ... con sus enlaces asociados.
BradC
@Jeff Atwood, @BradC: Lordy, difícil de encontrar. Vea esto: se basa en las recomendaciones de Intel. SQL Server utilizará la enumeración subyacente de Windows download.microsoft.com/download/5/7/7/… .
gbn
2

Desafortunadamente, no creo que vaya a obtener una respuesta más definitiva que "intente desactivar el hyperthreading y vea si eso ayuda".

A pesar de la útil respuesta de Jonathan en mi hilo original (que vinculaste en tu pregunta), nunca pude obtener ninguna evidencia definitiva sobre el impacto de HT en los servidores específicos que estaba investigando. En mi caso, los servidores ya estaban programados para el reemplazo, por lo que simplemente dejamos que esos reemplazos "se ocupen del problema", por así decirlo.

Mi consejo:

Pruebe una configuración de Grado máximo de paralelismo de nivel de servidor de 1 . El paralelismo en SQL es más útil para consultas más grandes y de mayor duración de todos modos, y su carga (supongo) consiste en un número enormemente alto de consultas más pequeñas de todos modos. Esto debería eliminar por completo las esperas de CXPACKET. Esto podría hacer que ciertas consultas individuales se ejecuten un poco más, pero debería permitir un mayor "rendimiento" de las consultas totales en el servidor.

He tenido buenos resultados haciendo esto en servidores OLTP. Otros tipos de servidores (servidores de informes, servidores de procesamiento, almacenamiento de datos) definitivamente necesitan que MAXDOP sea más alto.

Y para ser claros, esta configuración aún permitiría que SQL use múltiples subprocesos para cada tabla individual en un JOIN, por lo que no está eliminando el paralelismo por completo.

Al menos vale la pena intentarlo, ya que este cambio de configuración entra en vigencia inmediatamente y ni siquiera requiere que reinicie el servicio SQL: http://msdn.microsoft.com/en-us/library/ms181007.aspx
Esto significa que puede cambiar volvería inmediatamente si las cosas empezaran a ir al infierno.

Desactivar hyperthreading en el BIOS requeriría un reinicio completo del servidor, por lo que es un poco más arriesgado.

BradC
fuente
0

Para el registro, también tuvimos un rendimiento inesperadamente malo después de una actualización del servidor. Resultó ser debido a problemas con el BIOS y el ahorro de energía de la CPU. La configuración predeterminada en el servidor (HP) era ignorar el control del sistema operativo de la velocidad de la CPU y utilizar su propio algoritmo. Cambiar esto al control del sistema operativo y actualizar el BIOS resultó en mejoras significativas. Hubo algunas notas de la versión (no puedo encontrarlas ahora) de que había un error de BIOS que estaba bloqueando la CPU en el estado de rendimiento más bajo.

https://serverfault.com/a/196329/6390

Mark Sowul
fuente