Wysoki CXPACKET i LATCH_EX czekają

Mam pewne problemy z wydajnością systemu przetwarzania danych, nad którym pracuję. Zebrałem statystyki oczekiwania z przedziału godzinnego, które pokazują dużą liczbę zdarzeń oczekiwania CXPACKET i LATCH_EX.

System składa się z 3 przetwarzających serwerów SQL, które wykonują wiele obliczeń i obliczeń, a następnie przekazują dane do centralnego serwera klastrowego. Serwery przetwarzania mogą mieć jednocześnie do 6 zadań uruchomionych jednocześnie. Te statystyki czekania dotyczą centralnego klastra, który, jak sądzę, powoduje wąskie gardło. Centralny serwer klastrów ma 16 rdzeni i 64 GB pamięci RAM. MAXDOP jest ustawiony na 0.

Wydaje mi się, że CXPACKET pochodzi z wielu równoległych zapytań, ale nie jestem pewien, co oznacza zdarzenie oczekiwania LATCH_EX. Z tego, co przeczytałem, może to być oczekiwanie bez bufora?

Czy ktoś może zasugerować, jaka byłaby przyczyna tego rodzaju statystyk oczekiwania i jakie działania powinienem podjąć, aby zbadać pierwotną przyczynę tego problemu z wydajnością?

Górne wyniki zapytania to statystyki całkowitego oczekiwania, a dolne wyniki zapytania to statystyki z okresu 1 godziny

Do CXPACKET może towarzyszyć LATCH_XX (ewentualnie również PAGEIOLATCH_XX lub SOS_SCHEDULER_YIELD). Jeśli tak jest (i uważam, że tak jest, na podstawie pytania), wartość MAXDOP powinna zostać obniżona, aby pasowała do twojego sprzętu.

Oprócz tego, oto kilka bardziej zalecanych kroków w diagnozowaniu przyczyny wysokich wartości statystyki czekania CXPACKET (przed zmianą czegoś na SQL Server):

• Nie ustawiaj MAXDOP na 1, ponieważ nigdy nie jest to rozwiązanie

• Przejrzyj zapytanie i historię CXPACKET, aby zrozumieć i ustalić, czy jest to coś, co wystąpiło tylko raz czy dwa, ponieważ może to być wyjątek w systemie, który normalnie działa poprawnie

• Sprawdź indeksy i statystyki dotyczące tabel używanych przez zapytanie i upewnij się, że są aktualne

• Sprawdź próg kosztów dla równoległości (CTFP) i upewnij się, że zastosowana wartość jest odpowiednia dla twojego systemu

• Sprawdź, czy CXPACKET towarzyszy LCK_M_XX (zwykle towarzyszy IO_COMPLETION i ASYNC_IO_COMPLETION). W takim przypadku równoległość nie jest wąskim gardłem. Rozwiąż problemy ze statystykami oczekiwania, aby znaleźć podstawową przyczynę problemu i rozwiązanie

Jeśli naprawdę potrzebujesz dogłębnego zrozumienia typu oczekiwania CXPACKET, radzę przeczytać artykuł Rozwiązywanie problemów z typem oczekiwania CXPACKET w artykule SQL Server

Przeczytaj Diagnozowanie i rozwiązywanie problemów zatrzaskowych na SQL Server , jest najbardziej wyczerpującym artykułem na ten temat. Musisz się wkopać sys.dm_os_latch_statsi zobaczyć, na jakim typie zatrzasku jest rywalizacja.

Sprawdź, czy czytanie Jak analizować wydajność programu SQL Server, pomaga ci w jakikolwiek sposób.

Oprócz przeczytania powyższych linków i najprawdopodobniej zmiany ustawienia „Maksymalny stopień równoległości” z 0 na coś w rodzaju 8, będziesz chciał zawęzić zakres zapytań idących równolegle i ich koszt.

Po zobaczeniu wpływu tej zmiany możesz również rozważyć modyfikację swojego „progu kosztu dla równoległości”, aby dostosować to, co będzie równoległe.

Oto świetny film od Brenta Ozara, który pomoże ci: opanować sztukę CXPACKET i MAXDOP

Twoim celem jest <= 50% procent czasu oczekiwania na CXPACKET. Powodzenia!!