¿Quién está usando mis hilos de trabajo? SQL Server 2014 - HADR

Recientemente tuvimos un problema en nuestro entorno HADR de SQL Server 2014, donde uno de los servidores se quedó sin hilos de trabajo.

Recibimos el mensaje:

El grupo de subprocesos para los grupos de disponibilidad AlwaysOn no pudo iniciar un nuevo subproceso de trabajo porque no hay suficientes subprocesos de trabajo disponibles.

Ya abrí otra pregunta, para obtener una declaración que (pensé) debería ayudarme a analizar el problema ( ¿Es posible ver qué SPID usa qué planificador (hilo de trabajo)? ). Aunque ahora tengo la consulta para encontrar los hilos que usan el sistema, no entiendo por qué ese servidor se quedó sin hilos de trabajo.

Nuestro entorno es el siguiente:

• 4 Windows Server 2012 R2
• SQL Server 2014 Enterprise
• 24 procesadores -> 832 hilos de trabajo
• 256 GB de RAM
• 12 grupos de disponibilidad (general)
• 642 Bases de datos (en general)

Entonces, el servidor que tenía el problema tenía la siguiente configuración:

• 5 grupos de disponibilidad (3 primarios / 2 secundarios)
• 325 bases de datos (127 primarias / 198 secundarias)
• MAXDOP = 8
• Cost Threshold for Parallelism = 50
• El plan de energía está configurado en "Alto rendimiento"

Para "resolver" el problema, fallamos manualmente un grupo de disponibilidad en el servidor secundario. La configuración de ese servidor es ahora:

• 5 grupos de disponibilidad (2 primarios / 3 secundarios)
• 325 bases de datos (77 primarias / 248 secundarias)

Estoy monitoreando los hilos disponibles con esta declaración:

declare @max int
select @max = max_workers_count from sys.dm_os_sys_info

select 
    @max as 'TotalThreads',
    sum(active_Workers_count) as 'CurrentThreads',
    @max - sum(active_Workers_count) as 'AvailableThreads',
    sum(runnable_tasks_count) as 'WorkersWaitingForCpu',
    sum(work_queue_count) as 'RequestWaitingForThreads' ,
    sum(current_workers_count) as 'AssociatedWorkers'
from  
    sys.dm_os_Schedulers where status='VISIBLE ONLINE'

Normalmente, el servidor tiene alrededor de 250 a 430 subprocesos de trabajo disponibles, pero cuando comenzó el problema no quedaban trabajadores.

Hoy, de la nada, los trabajadores disponibles cayeron de 327 a 50, pero solo por un minuto y luego volvieron a subir a alrededor de 400.

Ya vi la otra pregunta ( uso de subprocesos de trabajo de HADR ) pero no me ayuda.

Nuestro sistema funcionó estable durante más de un año sin ningún problema. No hemos tenido ninguna conmutación por error u otro cambio importante en la distribución de las bases de datos.

Estamos utilizando "Confirmación sincrónica" entre las réplicas. Según tengo entendido, no hay compresión involucrada, vea Ajustar compresión para grupo de disponibilidad en la documentación.

¿Alguien tiene una idea de qué está utilizando todos los hilos de trabajo?

EDITAR: Encontré esta página donde hay mucha información sobre exactamente esos problemas http://www.techdevops.com/Article.aspx?CID=24

_{Respuesta wiki comunitaria :}

Tiene una gran cantidad de bases de datos en grupos de disponibilidad, ahí es donde van sus hilos. Hay mucho que ver con los costos de compresión, cifrado y transporte. Intente desactivar la compresión, reducirá el uso de su hilo en aproximadamente un tercio (dependiendo del recuento de réplicas).

La pregunta está etiquetada como SQL Server 2014, que por defecto utilizará la compresión. SQL Server 2016, de forma predeterminada, no utilizará la compresión para la sincronización.

Es posible que deba aumentar los hilos de trabajo en la instancia, o mejor: equilibre los más activos y los inactivos en varios servidores. Consulte la consulta de grupo de preguntas y respuestas de AlwaysON Availability muy lenta .

También puede encontrar que es una aplicación que no puede cerrar las solicitudes correctamente. Esto puede dar lugar a muchas sesiones de sueño por ahí (que consumen trabajadores).

El número de subprocesos realmente utilizados depende de qué tan activas estén las bases de datos. Podría tener 1,000 bases de datos y, si la mayoría están inactivas el 95% del tiempo, no tendrá ningún problema. Parece que sus bases de datos se han vuelto más activas y se han comido más hilos. Eso es todo.