Utilizzo elevato del thread di lavoro HADR

Perché il numero di thread di lavoro di un gruppo di disponibilità in un pool HADR dovrebbe aumentare ben oltre l'utilizzo minimo di "in genere, ci sono 3-10 thread condivisi " per replica?

In un caso abbiamo osservato l'utilizzo di oltre 300 thread con 3 gruppi di disponibilità e 10 database in totale. SQL Server 2014 SP1.

I nostri lead sono backup su replica secondaria, attività elevata su replica primaria, report su replica secondaria.

Gli AG si trovano in un datacenter su VMware. 16 programmatori in totale, i normali thread di lavoro rientrano nell'intervallo 200. max_dop sul server è 2.

3 AG, 10 DB, 4 repliche ciascuno - primario, 2 di sola lettura, 1 non leggibile.
1 secondario è synch, 2 asincrono
16 vcores su 32 core fisici su cluster multi host di grandi dimensioni.
Nessuna overprovision.
Altre VM più piccole 4-8 core sono raggruppate, ma non premono sulla CPU

Abbiamo osservato un picco nei thread di lavoro con conseguente negazione del servizio. Il nostro presupposto è l'attribuzione di thread di lavoro a AG, poiché solo i thread di lavoro possono superare il limite.

I collegamenti seguenti dal blog di SQL Server Premier Field Engineer, letti nel contesto, non mi danno una risposta completa:

— Alexander Tarasul
fonte

Puoi pubblicare esempi di screenshot di quello che stai vedendo? Qualcosa sembra fuori posto, come se stessi interrogando i thread di lavoro in generale anziché quelli di AG. (E anche altri thread di lavoro possono oltrepassare il limite, non solo quelli di AG.)

— Brent Ozar,

Sto cercando un problema simile. Abbastanza sicuro di averlo inchiodato al problema MaxDop. Sto usando gli script di Ola Hallengreens per IndexMaintenance e l'impostazione MaxDOP è stata impostata su NULL. Il punto è, potresti avere domande in arrivo, che hanno la precedenza su MaxDOP 2?

— Kasper Brandenburg,

Hai avuto qualche soluzione per questo?

— trusha,

-1

Poiché il controller di dominio è su VM, ho il sospetto che si stiano riscontrando scarse prestazioni del disco. Scarse prestazioni del disco possono comportare tempi di scrittura del log più lenti sul secondario, il che può comportare un riconoscimento più lento alla replica primaria dalla replica secondaria (esaurendo i thread di lavoro).

La latenza del disco sulla replica secondaria può causare un aumento del processo HADR Sync Commit, determinando che il primario mantiene i thread aperti mentre attende che il secondario riconosca la transazione.

Controllare il registro errori per gli Scheduler deadlock e raccogliere alcune metriche IO da PerfMon per vedere la latenza del disco e la lunghezza della coda del disco.

— Rodrigo Nascentes
fonte