28 votos

Se desactivación de hyperthreading mejorar el rendimiento de nuestra instalación de SQL Server

Relacionados con: la concepción Actual de SQL Server y Hyperthreading

Recientemente hemos actualizado nuestro Windows 2008 R2 servidor de base de datos a partir de un X5470 a un X5560. La teoría es que ambos modelos de Cpu de rendimiento muy similar, si nada de lo que el X5560 es ligeramente más rápido.

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

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

Cuando me encontré con:

SELECT * FROM sys.dm_os_wait_stats 
order by signal_wait_time_ms desc

Me dieron:

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 fila(s) afectado)

También corrí

-- 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 tengo

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

Que muestra una enorme cantidad de tiempo la sincronización de las consultas que implican paralelismo (alta CXPACKET). Además, como anécdota, muchos de estos problemas las consultas se ejecutan en múltiples núcleos (que no tienen MAXDOP sugerencias en cualquier parte de nuestro código)

El servidor no ha sido bajo carga para más de un día o así. Estamos experimentando una gran cantidad de varianza con ejecuciones de consulta, normalmente muchas de las consultas parecen ser más lento que estaban en nuestro anterior servidor de DB y la CPU es muy alto.

Se desactivación de Hyperthreading ayuda en la reducción de nuestro uso de la CPU y aumentar el rendimiento?

12voto

Jeff Atwood Puntos 31111

Estoy de acuerdo en que

  • en la mejor recomendación es "intentar HyperThreading en su carga de trabajo y ver qué pasa". Estamos haciendo ahora mientras escribo, y.. no es bueno!
  • probablemente, usted debe comenzar siempre con HyperThreading movilidad, ya que es más seguro

Parece que debería ser la sintonía de dos cosas:

  1. MAXDOP (Máximo Grados de Paralelismo). Todo lo que he leído indica que con este unbounded es probablemente una mala idea, y la documentación de Microsoft dice:

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

    algo más que 8 no se recomienda en general .. así que me puse a 4 por ahora. Era cero (unbounded) inicialmente.

  2. Umbral de costo para el Paralelismo. Al parecer, el defecto de 5 aquí se considera una muy baja defecto de acuerdo a un par de SQL MVP de posts que he encontrado, podemos afinar para reducir la cantidad de paralelismo es intentado por el programador.

Pero, honestamente, estas ganas de soluciones; creo que la verdadera solución para nuestra carga de trabajo (índice de texto completo pesada) para desactivar el HT.

10voto

Ilari Kajaste Puntos 989

Todavía siento que las pruebas de su carga de trabajo específica, como por la respuesta original, es la única manera de estar seguro. No es una respuesta ideal cuando usted está tratando de optimizar un sistema de producción (por eso me gustaría preguntar si era posible obtener idéntica de un banco de pruebas en sistemas donde el rendimiento y la disponibilidad importa realmente) pero es la única con la que me siento muy cómodo con.

Podemos hablar de la teoría de si o no Hyperthreading debe doler o de mejorar las cosas en general (me parece que es más probable que el daño que ayuda en los servidores por lo que para un "genérico" implementación probablemente me deshabilita), pero sólo hay una manera de ver si va a hacer una diferencia en tu caso concreto, y que se pruebe y vea.

9voto

automatonic Puntos 2830

Anandtech encontró que con el puro carga de lectura, me dolió un poco, y con una escritura de carga pesada, que era un poco de un triunfo. Yo no he visto nada que me hacen pensar que se va a obtener un éxito mucho peor que el de -5%, o una victoria mucho mejor que el 15%. Nota lo que con un Átomo, es una gran victoria, pero que es una muy extraña de la cpu.

Todo lo que cambió fue la cpu? Se pasó de 12 MB de caché y 4 hilos, así 3MB de caché por hilo, 8 MB de caché, y 8 subprocesos, por lo que 1MB por cada subproceso. Ahora, eso es simplificar demasiado, pero apuesto a que es lo que está matando a usted, que usted utiliza para ejecutar consultas en la cache, y ahora a cargo de ellos desde la RAM porque necesitan más de 1MB, pero menos de 3MB. Apagar HT probablemente va a ayudar, pero me gustaría volver a la vieja de la CPU. Apague HT, y se obtiene de 2MB por el hilo, pero si la carga de trabajo se agita con mucho, no va a ayudar. Bien puede ser que la edad de 12 mb de caché de la cpu es muy rápido para su carga de trabajo.

Me gustaría tratar de inflexión HT fuera, y ver si eso es una mejora, pero tengo la sospecha de que el caché es el rey de su carga de trabajo, y que también puede ser necesario volver a los 12 MB chip.

7voto

Shlomi Fish Puntos 1951

Hyperthreading es, en el mejor, simplemente una forma de abstracción de la tarea de conmutación distancia desde el sistema operativo y colocarlo en morir, con acceso directo a la L1 y la L2 caché, lo que hace que la tarea de conmutación de un crapload más rápido.

Prueba con VMWare han indicado que al desactivar el HT hecho hay una diferencia apreciable bajo carga estándar, y un aumento del 5% en condiciones de carga pesada, debido al hecho de que ESXi es lo suficientemente inteligente como para saber la diferencia entre lo "real" el hilo y el "falso" hilo (hay mucho más que eso, pero en laymens términos). SQL Server 2005 no es muy inteligente, pero combinado con un up-to-fecha de sistema operativo debería haber una pequeña ventaja a la desactivación de la hta.

Dicho todo esto, estoy de acuerdo con Ronald que lo más probable es que va a ser tu caché L2. Un 33% de caída en el tamaño de la caché es sustancial, y cuando nos especificaciones de nuestros Servidores SQL que siempre van para almacenar en caché en el raw de la velocidad de reloj a cada momento.

7voto

user55400 Puntos 1969

Basado en mi experiencia, HT estaba haciendo operaciones de e/S de tomar para siempre de mi de mi nodos activos en un Windows 2008 R2 (Clúster de SQL Server 2008 R2). Un hecho interesante fue que tampoco se refleja en la espera de estadísticas ni en el pssdiag me postulé para el soporte de Microsoft.

La forma en que me di cuenta de baja e/S fue sólo por ver el sistema operativo de los contadores de disco físico. Como Sam señaló, escribí sobre ello aquí y aquí

Si usted NO experimenta problemas de e/S y CPU sugiero que comienza de esta manera:

Identificar qué procesos y T-SQL bloques son causantes de la mayoría de utilización de la CPU. En nuestra experiencia, después de que se ha solucionado el problema con el I/O (girando HT off) hemos identificado el código que estaba realizando horriblemente en el año 2008 R2 y haciendo bien en el año 2005. Escribí sobre ello aquí.

Mientras que en condiciones de alta carga, ejecute Adam Machanic del sp_whoisactive. Se puede descargar desde aquí. Estábamos teniendo un muy alto uso de CPU debido a la excesiva cantidad de lecturas lógicas (20 millones de dólares por consulta) debido a un mal plan. Nuestros procesos se realiza anti-semi une con las tablas de particiones.

Mi siguiente recomendación es ejecutar el analizador de identificar un conjunto de T-SQL de código que son de alta en la CPU y de e/S de lecturas lógicas.

Con los pasos anteriores hemos sido capaces de sintonizar con la delincuencia de los procesos y de ir de un 85% sostenido que el uso de CPU casi nula.

Buena Suerte y por favor siéntase libre de dejarme una línea si usted encuentra una solución como me gustaría añadir que el caso de mi blog.

Gracias

Oscar

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: