Wysokie użycie wątku roboczego HADR

Dlaczego liczba wątków roboczych grupy dostępności w puli HADR wzrósłaby znacznie powyżej minimalnego użycia „ zwykle jest 3–10 wątków współdzielonych ” na replikę?

W jednym przypadku zaobserwowaliśmy użycie ponad 300 wątków z 3 grupami dostępności i 10 bazami danych ogółem. SQL Server 2014 z dodatkiem SP1.

Naszymi potencjalnymi klientami są kopie zapasowe w replice dodatkowej, duża aktywność w replice podstawowej, raporty na replice dodatkowej.

AG znajdują się w centrum danych na VMware. Łącznie 16 harmonogramów, zwykłe wątki robocze są poniżej 200. max_dop na serwerze to 2.

3 AG, 10 DB, po 4 repliki każda - podstawowa, 2 tylko do odczytu, 1 nieczytelna.
1 pomocniczy to synchronizacja, 2 asynchronizacja
16 vcores na 32 rdzeniach fizycznych na dużym klastrze z wieloma hostami.
Bez nadwyżki.
Inne mniejsze maszyny wirtualne 4-8 rdzeni są kolokowane, ale nie naciskają na procesor

Zauważyliśmy skok w wątkach roboczych, który spowodował odmowę usługi. Przypisanie wątków roboczych do AG jest naszym założeniem, ponieważ tylko te wątki robocze mogą przekroczyć limit.

Poniższe linki z bloga SQL Server Premier Field Engineer przeczytane w kontekście nie dają mi pełnej odpowiedzi:

— Alexander Tarasul
źródło

Czy możesz opublikować zrzuty ekranu z przykładami tego, co widzisz? Wydaje się, że coś jest nie tak, jak w przypadku zapytań w ogólności wątków roboczych, a nie w szczególności AG. (Także inne wątki robocze mogą przekroczyć limit, nie tylko AG).

— Brent Ozar

Poluję na podobny problem. Jestem prawie pewien, że udało mi się go przywiązać do problemu MaxDop. Używam skryptów Ola Hallengreens dla IndexMaintenance, a ustawienie MaxDOP ustawiono na NULL. Chodzi o to, czy możesz otrzymywać zapytania, które zastępują MaxDOP 2?

— Kasper Brandenburg

Czy masz na to jakieś rozwiązanie?

— trusha

-1

Ponieważ kontroler domeny działa na maszynie wirtualnej, podejrzewam, że wydajność dysku jest niska. Niska wydajność dysku może skutkować wolniejszym czasem zapisywania dziennika w pamięci pomocniczej, co może skutkować wolniejszym potwierdzeniem powrotu do repliki głównej z repliki wtórnej (wyczerpywanie wątków roboczych).

Opóźnienie dysku w replice dodatkowej może spowodować wzrost procesu zatwierdzania synchronizacji HADR, co spowoduje, że główny blokuje otwarte wątki podczas oczekiwania na potwierdzenie przez transakcję dodatkową.

Sprawdź dziennik błędów dla Deadlocked Schedulers i zbierz niektóre dane IO z PerfMon, aby zobaczyć opóźnienie dysku i długość kolejki dysku.

— Rodrigo Nascentes
źródło