Brent Ozar, Microsoft Certified Master, niedawno omówił równoległość w SQL Server, w szczególności typy oczekiwania CXPACKET i CXCONSUMER w swojej ostatniej części serii Quest Database Training Days Fall. W swoim zwykłym humorystycznym i przystępnym stylu Brent wyjaśnił pojęcie paralelizmu i wyjaśnił, jak sobie z nim radzić, gdy widzisz zbyt wiele statystyk oczekiwania CXPACKET i CXCONSUMER.
Po pierwsze, czym jest równoległość i dlaczego SQL Server sprawia, że zapytania są wykonywane równolegle?
Mówiąc najprościej, SQL Server automatycznie rozpoznaje, że dane zapytanie wiąże się z dużym obciążeniem i określa, że praca może być wykonywana wydajniej na wielu procesorach niż tylko na jednym. Jest to na ogół rozsądna decyzja, ale może wpaść w kłopoty, gdy SQL Server nie równoważy obciążenia w wątkach wykonujących zadanie.
Zrozumienie typów oczekiwania CXPACKET i CXCONSUMER
CXPACKET i CXCONSUMER to typy oczekiwania, które wskazują, że praca nie jest równomiernie zrównoważona. Gdy zobaczysz te statystyki oczekiwania na swoim serwerze, będziesz wiedział, że SQL Server wykonuje zapytania równolegle, ale nie radzi sobie dobrze z dystrybucją ich na dostępne procesory.
Każdy specjalista ds. baz danych jest zaznajomiony z pojęciem „kosztu”, aby wyrazić, jak kosztowne jest wykonanie zapytania pod względem zużycia zasobów. Te „dolary za zapytania” są przybliżoną miarą pracy i ważnym sygnałem, czy zapytanie będzie działać równolegle, czy nie. Niedrogie zapytanie nie będzie musiało działać równolegle, ale drogie tak. Celem jest wykonanie zapytania tak szybko i wydajnie, jak to możliwe, aby można było rozpocząć następne w kolejności. SQL Server wyznacza wątek jako harmonogram, a ten wątek, który Brent uznał za „nadrzędnego robota”, przypisze części obciążenia równoległego do wątków roboczych lub „sługusów robotów”.
Parallelism and the robot overlord
Brent zanurkował w demo, aby pokazać, jak to działa. Korzystając z bazy danych Stack Overflow, stworzył tanie wyszukiwanie bazy danych, które było bardzo szybkie ze względu na obecność indeksu. Plan wykonania był dość prosty i nie wymagał równoległości.
Kiedy jednak wprowadził wyszukiwanie czegoś, czego nie było w indeksie, sytuacja zmieniła się, wymuszając wyszukiwanie klucza dla każdego wiersza w indeksie klastrowym tabeli. SQL Server uznał, że wymagałoby to dużo pracy, więc wprowadził równoległość i oznaczył jako taki ikoną na planie wykonania. Gdyby plan wykonania był trójwymiarowy, byłbyś w stanie zobaczyć wiele wątków ułożonych w stos, ale ponieważ tak nie jest, musisz wyświetlić statystyki, aby zobaczyć informacje, takie jak odczyty logiczne wykonywane przez każdy wątek procesora.
Jednak SQL Server przypisał to zadanie tylko do kilku wątków, a nie do wszystkich. Brent wyjaśnił, że wszystko, co dzieje się poza ikoną równoległą, dzieje się tylko na przypisanych procesorach. Tak więc wątki, które wykonały początkowe odczyty, są teraz jedynymi wykonującymi również wyszukiwanie kluczy. Władca robotów poprosił tylko kilka sługusów o wykonanie całego zadania, zamiast prosić wszystkie sługi, aby się zgłosiły.
Następnie wyjaśnił, że SQL Server musi uwzględniać, co robią wątki, a także śledzić, co robi nadrzędny robot. Na początku cała ta praca była reprezentowana przez jedną statystykę oczekiwania, ale to nie miało sensu, ponieważ bez względu na wszystko, mroczny władca nadal musi czekać, aż wszystkie wątki działają. Wprowadzono więc nowy typ oczekiwania – był to CXCONSUMER i śledzi on, co robi wątek harmonogramu/nadrzędnego, podczas gdy CXPACKET śledzi, co robią wątki pracowników/minionów.
Brent wrócił do zapytania, aby jeszcze bardziej je skomplikować, dodając sortowanie. Teraz staje się jeszcze bardziej jasne, że równoległość powoduje problem, a nie czyni operację bardziej wydajną. Praca stała się jeszcze bardziej niezrównoważona w kilku wątkach roboczych, a niektórym kończy się pamięć i rozlewa się na dysk. Dodał sprzężenie, jeszcze bardziej obciążając działające rdzenie, które nie otrzymują żadnej pomocy od niepracujących. Statystyki CXPACKET nadal rosły.
Co możesz zrobić w tej sytuacji? Decyzja o równoległości ma miejsce na poziomie serwera, a nie na poziomie zapytania, więc wymaga pewnych zmian w konfiguracji.
Ocenianie konfiguracji kluczy
Dowiedzieliśmy się już, że jeśli koszt zapytania jest wyższy niż pewien poziom, powoduje to zrównoleglenie SQL Server. Małe zapytania są ograniczone do jednego wątku. Ale co kontroluje próg? Jest to właściwość o nazwie Cost Threshold for Parallelism (CTFP). Domyślnie, jeśli plan wykonania określa, że koszt jest wyższy niż 5 dolarów za zapytanie, zapytanie zostanie zrównoleglone. Chociaż nie ma wskazówek, jak to ustawić, Brent zaleca liczbę większą niż 50. Pozwoli to pozbyć się paralelizmu w przypadku trywialnych zapytań.
Inną konfiguracją jest maksymalny stopień równoległości (MAXDOP), który opisuje liczbę wątków, które SQL Server przypisze do zapytania. Wartość domyślna to zero, co oznacza, że SQL Server może użyć wszystkich dostępnych procesorów, do 64, do wykonania zapytania. Ustawienie opcji MAXDOP na 1 ogranicza SQL Server do używania tylko jednego procesora – w efekcie wymuszając wykonanie zapytania przez plan szeregowy. SQL Server zaleci wartość MAXDOP w oparciu o liczbę posiadanych rdzeni serwera, ale ogólnie niższa wartość MAXDOP ma sens, ponieważ nie będzie wiele razy, gdy wszystkie rdzenie będą potrzebne.
Brent wprowadził poprawki w tych dwóch konfiguracjach i ponownie uruchomił zapytanie. Tym razem mogliśmy zobaczyć, że do operacji równoległej zaangażowanych było więcej rdzeni. Statystyki oczekiwania CXPACKET były niższe, co oznaczało, że obciążenie było bardziej równomiernie rozłożone na większej liczbie rdzeni niż wcześniej.
Wskazówki dotyczące zwalczania statystyk oczekiwania CXPACKET i CXCONSUMER
Brent zaleca następujące kroki, jeśli widzisz nadmierne statystyki oczekiwania CXPACKET i CXCONSUMER:
- Ustaw CTFP i MAXDOP zgodnie z najlepszymi praktykami branżowymi, a następnie pozostaw te ustawienia przez kilka dni. Spowoduje to wyczyszczenie pamięci podręcznej planów i zmusi SQL Server do odbudowania planów wykonania zapytań (ponowna ocena kosztów).
- Wprowadź ulepszenia indeksu, które skrócą czas, w którym zapytania są wykonywane równolegle w celu skanowania i sortowania. Pozwól nowym indeksom się upiec, a następnie poszukaj zapytań, które nadal wykonują dużo pracy.
- Dostosuj te zapytania i pozwól im piec przez kilka dni.
- Na koniec, jeśli równoległość jest nadal poważnym problemem, zacznij szukać konkretnych zapytań z problemami z równoległością.
Aby uzyskać jeszcze więcej informacji, możesz obejrzeć całą sesję szkoleniową Brenta na temat statystyk oczekiwania na żądanie CXPACKET i CXCONSUMER poniżej.
