SQL Server: ¿Alguien usa SUMA, el indicador de seguimiento 8048 o el indicador de seguimiento 8015?

Recientemente incluí el inicio de SQL Server Trace Flag 8048 para resolver un serio problema de contención de spinlock en un sistema SQL Server 2008 R2.

Interesado en escuchar de otros que han encontrado casos de uso donde el valor de rendimiento fue entregado por la marca de seguimiento 8048 (promueve la estrategia de concesión de memoria de consulta de nodo por NUMA a por núcleo), la marca de seguimiento 8015 (SQL Server ignora NUMA físico) o SUMA ( acceso a memoria suficientemente uniforme entrelazado, una opción de BIOS en algunas máquinas NUMA).

Trace flag 8048 http://blogs.msdn.com/b/psssql/archive/2011/09/01/sql-server-2008-2008-r2-on-newer-machines-with-more-than-8-cpus -presented-per-numa-node-may-need-trace-flag-8048.aspx

Trace flag 8015 http://blogs.msdn.com/b/psssql/archive/2010/04/02/how-it-works-soft-numa-io-completion-thread-lazy-writer-workers-and-memory -nodes.aspx

Detalles sangrientos de la carga de trabajo del sistema, métricas recopiladas del sistema con problemas y métricas recopiladas del sistema después de la intervención de seguimiento.

La marca de seguimiento 8048 era una "solución", pero ¿era la mejor solución? ¿SQL Server ignorando el NUMA físico debido al indicador de rastreo 8015 habría logrado lo mismo? ¿Qué pasa con la configuración del BIOS para intercalar memoria, dejando al servidor con el comportamiento SUMA que imita a SMP en lugar del comportamiento NUMA?

¡Paz! tw: @sql_handle

Acerca del sistema: - 4 núcleos hexadecimales Xeon E7540 @ 2.00GHz, hyperthreaded - 128 GB de RAM - WS2008R2 - MSSQL 2008 R2 SP2 - maxdop 6

Acerca de la carga de trabajo: - 1000 de informes programados / en cola de Batch conducidos desde 2 servidores de aplicaciones de informes. - 3 tipos de lotes: diario, semanal, mensual - Todas las conexiones de servidores de aplicaciones de informes a SQL Server se realizan como una sola cuenta de servicio - Concurrencia máxima de informes = 90

Hallazgos clave sobre el sistema con problemas: - Desde Perfmon, intervalos de 15 segundos - - El sistema permanece en un 95% -100% de CPU ocupada - - Búsquedas en la página de búfer de SQL Server <10000 por / segundo

• Desde los DMV de espera y spinlock, intervalos de 5 minutos
• • Alto CMEMTHREAD camareros y tiempo de espera
• • SOS_SUSPEND_QUEUE altos giros y retrocesos

La publicación de blog del ingeniero CSS de Bob Dorr en el indicador de rastreo 8048 indica que los sistemas con más de 8 núcleos por nodo NUMA pueden presentar síntomas similares debido a un cuello de botella en la concesión de memoria de consulta. La marca de seguimiento 8048 cambiará la estrategia a por núcleo en lugar de por nodo NUMA.

La intervención

MSSQL se reinició con -T8048 en su lugar. La diferencia fue evidente de inmediato: la tasa de búsqueda de páginas de memoria intermedia aumentó más de 1 millón y aumentó a 8 millones por segundo. La carga de trabajo por lotes con problemas, que anteriormente no se podía completar en 24 horas, se completó en menos de 4 horas. Se presentó otra carga de trabajo por lotes que no era el foco de investigación o intervención como parte de la validación del valor correctivo del indicador de traza 8048 (y se aseguró de que sus efectos secundarios no deseados fueran mínimos). Este lote de informes se completó previamente en 2 horas; con la marca de seguimiento 8048 en su lugar, el lote de informes se completó en aproximadamente 20 minutos.

El ETL nocturno también encontró un beneficio. El tiempo de ETL se redujo de aproximadamente 60 minutos a 40 minutos.

Recopilando información de varios lugares, especulo que el alto grado de cola de informes, el recuento de informes concurrentes mayor que el recuento de subprocesos de hardware y la cuenta de usuario único para todos los informes combinados para ejercer presión sobre un nodo NUMA hasta que la presión del subproceso de los trabajadores lo hizo se desfavorecerá para la próxima solicitud de conexión entrante para la misma cuenta de usuario, momento en el cual el siguiente nodo NUMA obtendría cierta cantidad de conexiones casi instantáneamente. Cada nodo NUMA terminaría con una alta probabilidad de estresar el cuello de botella de concesión de memoria de consulta.

Al abrir más carriles para la memoria de consulta se eliminó el cuello de botella. Pero no estoy seguro del costo. La publicación CSS de Bob Dorr deja en claro que hay una sobrecarga de memoria adicional con el indicador de traza 8048. ¿Es esa sobrecarga dentro de la región del asignador de una sola página gobernada por la memoria máxima del servidor MSSQL 2008 R2? Si es así, supongo que el sistema tendrá un número menor de páginas de base de datos en la memoria caché de la agrupación de almacenamiento intermedio. Si no es así, ¿debería reducirse la memoria máxima del servidor para acomodar?

Esta es una publicación impresionante.

Para responder a su pregunta final, especularía que su respuesta es "sí".

Dicho esto, probablemente habría seguido a numa suave antes de recurrir a las banderas de rastreo. Creo que tiene razón acerca de la asignación del nodo numa y eso podría ser la raíz de su problema. A través de soft numa, puede escalar las solicitudes, dependiendo de su recuento de nodos numa (4?) - a 4, si ese es el número correcto, y luego asignar, a través de la dirección IP, cada host a un nodo numa específico, además para eso, deshabilitaría hyper threading. Combinado, el problema probablemente disminuiría, sin embargo, lo haría a costa de menos programadores.

Pensándolo por separado, consideraría la parametrización forzada: el hecho de que su carga esté impulsando su CPU tan alto es muy interesante y puede valer la pena analizarlo.

Por último, en los sistemas de nodos multi-numa, normalmente tengo el resultado de las siguientes consultas volcado en una tabla cada N segundos. Hace un análisis interesante cuando se implementan cambios en la carga de trabajo o se implementan indicadores de seguimiento:

SELECT getdate() as poll_time, node_id, node_state_desc, memory_node_id, online_scheduler_count, active_worker_count, avg_load_balance, idle_scheduler_count
FROM sys.dm_os_nodes WITH (NOLOCK) 
WHERE node_state_desc <> N'ONLINE DAC'

y

SELECT top 10 getdate() as sample_poll, wait_type, count (*)
FROM sys.dm_os_waiting_tasks
WHERE [wait_type] NOT IN
('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK','SLEEP_SYSTEMTASK',
'SQLTRACE_BUFFER_FLUSH','WAITFOR', 'BROKER_TASK_STOP',
'BROKER_RECEIVE_WAITFOR', 'OLEDB','CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT' ) 
GROUP BY wait_type
ORDER BY COUNT (*) DESC