Necesita comprender el error de ejecución de consultas paralelas

Hoy hemos experimentado una degradación en el rendimiento de nuestro servidor sql de producción. Durante el tiempo que esto ocurrió, registramos varios "The query processor could not start the necessary thread resources for parallel query execution"errores. La lectura que he hecho sugiere que esto tiene que ver con cuántas CPU usar al ejecutar una consulta compleja. Sin embargo, cuando revisé durante la interrupción nuestra CPU Utilization was only at 7%. ¿Hay algo más a lo que esto podría referirse que aún no he encontrado? ¿Es esto un probable culpable de la degradación del rendimiento o estoy persiguiendo un arenque rojo?

Mis valores de sp_configure para esto son los siguientes:

name                                minimum maximum config_value run_value
cost threshold for parallelism      0       32767   5            5

Hace unos meses, me enfrenté a una situación similar en la que la configuración MAXDOP era predeterminada y una consulta de escape agotó todos los hilos de trabajo.

Como Remus señaló, esto se llama hambruna de hilos de trabajo .

Habrá un volcado de memoria creado en su servidor cuando se produjo esta condición.

Si está en 2008R2 + SP1 y en adelante, también sys.dm_server_memory_dumpsle dará la ubicación del archivo de volcado.

Ahora volviendo al problema:

Hay 1 subproceso de monitor de planificador por nodo NUMA y dado que tiene 2 nodos NUMA, habrá 2 subprocesos de monitor de planificador que son responsables de la comprobación del estado de todos los planificadores cada 60 segundos para ese nodo NUMA en particular mientras se asegura de que el planificador esté atascado o no.

Cada vez que se extrae una nueva solicitud de trabajo de la cola de trabajo del planificador, el contador de procesos de trabajo se incrementa. Entonces, si el planificador tiene una solicitud de trabajo en cola y no ha procesado una de las solicitudes de trabajo en 60 segundos, el planificador se considera bloqueado.

Debido a una consulta de fuga o un paralelismo extenso, surge la condición de que los subprocesos de trabajo comiencen a agotarse, ya que todos los subprocesos están ocupados por esa única consulta de huida o bloqueo prolongado excesivo y no se puede realizar ningún trabajo a menos que se elimine ese proceso ofensivo.

Su mejor opción es sintonizar primero su configuración de Grado máximo de paralelismo . El valor predeterminado de 0 significa que SQL Server puede usar todas las CPU disponibles para el procesamiento paralelo y agotar todos los subprocesos de trabajo.

Hay muchas razones que pueden llevar al agotamiento de los hilos de trabajo:

• Extensas cadenas de bloqueo largas que hacen que SQL Server se quede sin hilos de trabajo
• Amplio paralelismo que también lleva al agotamiento de los hilos de trabajo
• Espera extensa para cualquier tipo de "cerradura": cerraduras giratorias, pestillos. Un spinlock huérfano es un ejemplo.

Consulte mi respuesta aquí que le mostrará cómo puede calcular el valor MAXDOP para su instancia de servidor.

Además, le recomiendo que comience a recopilar información de estadísticas de espera sobre la instancia del servidor de su base de datos.

Podría haber varias razones. Lo más probable es que se haya quedado sin trabajadores. Ver max_worker_threads. La condición se llama 'estravación del trabajador'. Los trabajadores podrían ser robados por cualquiera de los múltiples medios (ninguno de los cuales resultaría en una alta utilización de la CPU, por cierto), como tener muchas solicitudes bloqueadas o hacer cosas estúpidas en CLR (por ejemplo, solicitudes HTTP).

El síntoma que ve es la víctima del problema, no la causa. No podemos recomendar una solución sin conocer la causa. Debe recopilar contadores de rendimiento, DMV y consultar ERRORLOG para obtener más información.