HADR alto uso de subprocesos de trabajo

¿Por qué el número de subprocesos de trabajo de un grupo de disponibilidad en un grupo HADR aumentaría mucho más allá del uso mínimo de " típicamente, hay 3 a 10 subprocesos compartidos " por réplica?

En un caso, hemos observado el uso de más de 300 subprocesos con 3 grupos de disponibilidad y 10 bases de datos en total. SQL Server 2014 SP1.

Nuestros clientes potenciales son copias de seguridad en réplica secundaria, alta actividad en réplica primaria, informes en réplica secundaria.

Los AG están en un centro de datos en VMware. 16 planificadores en total, los subprocesos de trabajo habituales están por debajo del rango 200. max_dop en el servidor es 2.

3 AG, 10 DB, 4 réplicas cada una: primaria, 2 de solo lectura, 1 no legible.
1 secundaria es sincronización, 2 asíncronas
16 vcores en 32 núcleos físicos en un gran clúster de host múltiple.
Sin sobreprovisión.
Otras máquinas virtuales más pequeñas de 4 a 8 núcleos están ubicadas, pero no presionan la CPU

Observamos un aumento en los hilos de los trabajadores que resulta en la denegación de servicio. La atribución de hilos de trabajo a AG es nuestra suposición, ya que solo esos hilos de trabajo pueden cruzar el límite.

Los enlaces a continuación del Blog del Ingeniero de campo Premier de SQL Server leídos en contexto no me dan una respuesta completa:

— Alexander Tarasul
fuente

¿Puedes publicar ejemplos de capturas de pantalla de lo que estás viendo? Algo parece raro aquí, como si estuvieras consultando hilos de trabajo en general en lugar de específicamente los AG. (Y otros hilos de trabajo también pueden cruzar el límite, no solo los AG).

— Brent Ozar

Estoy buscando un problema similar. Estoy bastante seguro de que lo he clavado en el problema de MaxDop. Estoy usando scripts de Ola Hallengreens para IndexMaintenance, y la configuración MaxDOP se estableció en NULL. El punto es, ¿podrían recibir consultas que anulen su MaxDOP 2?

— Kasper Brandenburg

¿Obtuviste alguna solución para esto?

— Trusha

-1

Dado que su DC está en la VM, sospecho que está experimentando un bajo rendimiento del disco. El bajo rendimiento del disco puede provocar tiempos de escritura de registro más lentos en el secundario, lo que puede provocar un reconocimiento más lento de la réplica principal desde la réplica secundaria (subprocesos de trabajo agotadores).

La latencia de disco en la réplica secundaria puede causar un aumento en el proceso de confirmación de sincronización HADR, lo que da como resultado que el primario mantenga subprocesos abiertos mientras espera que el secundario reconozca la transacción.

Verifique el registro de errores de los Programadores Deadlocked y recopile algunas métricas de E / S de PerfMon para ver la latencia del disco y la longitud de la cola del disco.

— Rodrigo Nascentes
fuente