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?
fuente
Respuestas:
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.
fuente
Estoy de acuerdo que
Parece que deberíamos ajustar dos cosas:
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:
algo más alto de
8lo que generalmente no se recomienda ... así que lo configuré4por ahora. Fue cero (ilimitado) inicialmente.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.
fuente
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.
fuente
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.
fuente
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
fuente
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
fuente
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.
fuente
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
fuente