Przez ostatnie 18 miesięcy skupiałem się na odruchowych reakcjach na analizę statystyk oczekiwania i inne tematy związane z dostrajaniem wydajności. W tym poście zamierzam to kontynuować i omówić PAGELATCH_XX czeka. XX na końcu oczekiwania oznacza, że istnieje wiele typów PAGELATCH czekaj, a najczęstsze przykłady to:
- PAGELATCH_SH – ( SH są) czekają na dostęp do strony pliku danych w pamięci, aby można było odczytać zawartość strony
- PAGELATCH_EX lub PAGELATCH_UP – (EX łączny lub W GÓRĘ data) oczekiwanie na dostęp do strony pliku danych w pamięci, aby zawartość strony mogła zostać zmodyfikowana
Kiedy jeden z tych typów oczekiwania jest najbardziej rozpowszechniony na serwerze, odruchową reakcją jest to, że problem ma coś wspólnego z I/O (tj. pomyłka z PAGEIOLATCH_XX typ oczekiwania, który omówiłem w poście w 2014 roku) i ktoś próbuje dodać więcej pamięci lub poprawić podsystem I/O. Żadna z tych reakcji nie przyniesie żadnego efektu, ponieważ strony plików danych, których dotyczy rywalizacja, są już w pamięci w puli buforów!
We wszystkich przypadkach możesz sprawdzić, czy masz problem z PAGELATCH_XX rywalizacja za pomocą sys.dm_os_waiting_tasks na moim blogu lub za pomocą narzędzia takiego jak Performance Advisor, jak pokazano (dla innego typu oczekiwania) w tym poście.
Więc jakie jest źródło sporu? Najpierw wyjaśnię tło tych typów oczekiwania, a następnie omówię dwie najczęstsze przyczyny PAGELATCH_XX spór.
Tło:Zatrzaski
Zanim przejdę do niektórych przyczyn PAGELATCH_XX czekam, chcę wyjaśnić, dlaczego w ogóle istnieją.
W każdym systemie wielowątkowym struktury danych, do których można uzyskać dostęp i którymi można manipulować za pomocą wielu wątków, muszą być chronione, aby zapobiec scenariuszom, takim jak:
- Dwa wątki aktualizują strukturę danych jednocześnie, a niektóre aktualizacje są tracone
- Wątek aktualizujący strukturę danych jednocześnie z innym wątkiem czytającym strukturę danych, więc wątek czytający widzi mieszankę starych i nowych danych
To podstawa informatyki, a SQL Server niczym się nie różni, więc wszystkie struktury danych wewnątrz SQL Server muszą mieć wielowątkową kontrolę dostępu.
Jednym z mechanizmów używanych w tym celu przez SQL Server jest zatrzask, w którym trzymanie zatrzasku w trybie wyłączności uniemożliwia innym wątkom dostęp do struktury danych, a trzymanie zatrzasku w trybie udostępniania uniemożliwia innym wątkom zmianę struktury danych. SQL Server używa również blokad spinlock dla niektórych struktur danych i omówiłem je w tym poście w 2014 roku.
Ale możesz się zastanawiać, dlaczego strona pliku danych w pamięci jest chroniona zatrzaskiem? Cóż, strona pliku danych jest tylko strukturą danych, aczkolwiek do celów specjalnych, a zatem wymaga takiej samej kontroli dostępu, jak każda inna struktura danych. Jeśli więc jeden wątek musi zmodyfikować stronę pliku danych, musi uzyskać blokadę wyłączności lub aktualizację na stronie, a jeśli nie może i musi poczekać, typ oczekiwania PAGELATCH_EX lub PAGELATCH_UP wyniki.
Klasyczna rywalizacja o tempdb
PAGELATCH rywalizacja w tempdb dotyczy zazwyczaj bitmap alokacji i występuje w przypadku obciążeń z wieloma współbieżnymi połączeniami, które tworzą i usuwają małe tabele tymczasowe (które są przechowywane w tempdb).
Po wstawieniu pierwszego wiersza do tabeli tymczasowej należy przydzielić dwie strony (stronę danych i stronę uprawnień, która śledzi stronę danych). Te strony muszą byćoznaczone jako przydzielone na specjalnej stronie przydziału zwanej stroną PFS i domyślnie sąprzydzielane ze specjalnych zakresów danych śledzonych przez inną stronę przydziału nazywaną stroną SGAM (szczegóły można znaleźćw moim starym poście na blogu tutaj). Kiedy tabela tymczasowa zostanie usunięta, strony te muszą zostać ponownie zwolnione, co wymaga dalszych zmian na stronach PFS i SGAM.
Jeśli tabele tymczasowe są małe, a łączny rozmiar wszystkich współbieżnie tworzonych tabel tymczasowych jest mniejszy niż 64 MB, wszystkie te zmiany bitmap alokacji są wyśrodkowane na pierwszych stronach PFS i SGAM w pliku danych tempdb (z identyfikatorem strony (1:1) i (1:3) odpowiednio). Aktualizacja jednej z tych stron alokacji wymaga zatrzaśnięcia strony, a tylko jeden wątek na raz może zmieniać stronę, więc wszystkie inne wątki muszą czekać – z typem oczekiwania PAGELATCH_UP .
Począwszy od SQL Server 2005, tymczasowe tabele mogą być buforowane po upuszczeniu, o ile ich rozmiar jest mniejszy niż 8 MB (a w SQL Server 2014 nie są tworzone w procedurze składowanej, która również zawiera instrukcje DDL w tabeli tymczasowej). Oznacza to, że następny wątek, który wykonuje ten sam plan zapytania, może usunąć tabelę tymczasową z pamięci podręcznej i nie musi zajmować się początkowymi alokacjami. Ogranicza to rywalizację o mapy bitowe alokacji, ale pamięć podręczna tabel tymczasowych nie jest zbyt duża, więc obciążenia z setkami współbieżnie tworzonych/porzucanych tabel tymczasowych nadal będą powodować dużą rywalizację.
Trywialne jest zapobieganie rywalizacji na stronach SGAM w tempdb poprzez włączenie udokumentowanej flagi śledzenia 1118 na serwerze, która, jak mówię, powinna być włączona na wszystkich serwerach na całym świecie i jest w rzeczywistości niezmiennym domyślnym zachowaniem w SQL Server 2016.
Zapobieganie rywalizacji na stronach PFS w tempdb jest nieco trudniejsze. Zakładając, że tabele tymczasowe są potrzebne do zapewnienia wydajności, sztuczka polega na tym, aby mieć wiele plików danych dla tempdb, aby alokacje odbywały się w systemie round-robin między plikami, rywalizacja jest dzielona na wiele stron PFS, a więc ogólna rywalizacja spada. Niestety nie ma właściwej odpowiedzi na to, ile plików danych powinieneś mieć. Więcej informacji na temat ogólnie przyjętych wskazówek na ten temat można znaleźć w artykule KB 2154845 oraz w tym poście na blogu.
Wstaw hotspot
W bazach danych użytkowników częsta przyczyna dużej liczby PAGELATCH_EX wait to hotspot wstawiania.
Może się tak zdarzyć, gdy tabela ma indeks klastrowy z kluczem klastra int lub bigint, a rozmiar wiersza jest wystarczająco mały, aby na stronie danych na poziomie liścia indeksu klastrowanego zmieściło się wiele dziesiątek lub więcej wierszy tabeli.
W przypadku takiej tabeli, jeśli obciążenie obejmuje wiele dziesiątek lub setek równoczesnych wątków wstawianych do tabeli, wiele wątków wygeneruje wiersze z wartościami tożsamości (a tym samym kluczami klastrów), które należy wstawić na tej samej stronie danych na poziomie liścia .
Teraz pamiętaj, że wprowadzanie jakichkolwiek zmian na stronie pliku danych w pamięci wymaga wyłącznego zatrzasku, więc każdy z wątków próbujących wstawić na tę samą stronę musi uzyskać wyłączność zatrzasku strony. Podczas gdy każdy wątek trzyma wyłączny zatrzask, inne wątki będą czekać na PAGELATCH_EX dla tej strony, zasadniczo czyniąc współbieżne wstawianie w bardzo wąskim gardle procesu synchronicznego.
Istnieje kilka możliwych rozwiązań tego problemu:
- Użyj bardziej losowego klucza i pamiętaj, że doprowadzi to do fragmentacji indeksu, więc skorzystaj również ze współczynnika wypełnienia indeksu, aby zapobiec podziałom stron
- Rozłóż wkładki w tabeli za pomocą pewnego rodzaju sztucznego mechanizmu partycjonowania
- Użyj większego rozmiaru wiersza w tabeli (jest to oczywiście najmniej smaczna opcja)
Widziałem taki punkt aktywny wstawiania, jak ten, który pojawia się, gdy ktoś próbował usunąć problemy z fragmentacją indeksu, zmieniając losowy klucz klastra GUID na klucz klastra tożsamości int lub bigint, ale nie udało się przetestować nowego schematu tabeli pod obciążeniem produkcyjnym.
Podsumowanie
Podobnie jak w przypadku innych typów oczekiwania, dokładnie rozumiesz, co PAGELATCH_XX Średnia oczekiwania jest kluczem do zrozumienia, jak je rozwiązywać.
Jeśli chodzi o ogólne statystyki oczekiwania, więcej informacji na temat ich używania do rozwiązywania problemów z wydajnością można znaleźć w:
- Moja seria wpisów na blogu SQLskills, zaczynająca się od statystyk Wait lub proszę powiedz mi, gdzie to boli
- Moja biblioteka typów Wait Types i Latch Classes tutaj
- Mój kurs szkoleniowy online Pluralsight SQL Server:Rozwiązywanie problemów z wydajnością za pomocą statystyk oczekiwania
- Doradca wydajności SQL Sentry
Miłego rozwiązywania problemów do następnego razu!
