Rozwiązywanie problemów z wydajnością to sztuka i nauka. Sztuka pochodzi z doświadczenia (i uczenia się na podstawie doświadczeń innych), a nauka pochodzi ze znanych wytycznych dotyczących tego, co robić w jakich scenariuszach.
A przynajmniej tak lubię myśleć i uczyć.
W rzeczywistości wielu administratorów baz danych i programistów praktykuje coś, co nazywam „rozwiązywaniem problemów z wydajnością z podskokiem”. Dzieje się tak często, gdy problem z wydajnością osiągnął krytyczny etap, na przykład w wyniku przekroczenia limitu czasu zapytań, powolnych procesów lub awarii procesów, niezadowolonych użytkowników, a kierownictwo oczekuje odpowiedzi i szybkiego działania!
„Szarpienie za kolano” pochodzi z wykonania powierzchownej analizy problemu i pochopnego wniosku (tak naprawdę jest to chwytanie się brzytwy), że najbardziej rozpowszechnionym objawem musi być przyczyna i próba rozwiązania tego problemu, bez skutku lub z niewielkim skutkiem. często korzystając z błędnych lub wręcz niepoprawnych porad znalezionych w Internecie. Prowadzi to do dużej frustracji i marnowania czasu, a często prowadzi do zmarnowania pieniędzy, gdy organizacja postanawia spróbować rozwiązać problem ze sprzętem poprzez modernizację serwera i/lub podsystemu we/wy, tylko po to, by stwierdzić, że problem nadal istnieje lub pojawia się ponownie dość szybko.
Analiza statystyk oczekiwania to jeden z obszarów, w których najłatwiej jest odruchowo, a w tym poście opowiem o kilku typowych typach czekania i błędach, które ludzie popełniają wokół nich. W artykule takim jak ten nie ma możliwości zagłębienia się w to, co należy zrobić w każdym przypadku, ale dam ci wystarczająco dużo informacji, aby wskazać ci właściwy kierunek.
LCK_M_XX
Większość ludzi zakłada, że jeśli oczekiwanie na blokowanie jest najbardziej rozpowszechnione, to musi to być jakiś problem z blokowaniem, który jest problemem. Często tak jest, na przykład brak odpowiedniego indeksu nieklastrowego powoduje skanowanie tabeli na poziomach izolacji REPEATABLE_READ lub SERIALIZABLE, które eskaluje do blokady tabeli S. (I jako krótka wskazówka, jeśli nie wydaje Ci się, że kiedykolwiek używasz opcji SERIALIZABLE, robisz to, jeśli korzystasz z transakcji rozproszonych – wszystko jest konwertowane na SERIALIZABLE pod osłonami, co może prowadzić do nieoczekiwanych blokad i zakleszczeń.)
Jednak często zdarza się, że blokowanie jest spowodowane czymś innym. Na domyślnym poziomie izolacji READ_COMMITTED blokady obejmujące zmiany są utrzymywane do momentu zatwierdzenia transakcji i będą blokować odczyty i inne aktualizacje tych samych wierszy. Jeśli cokolwiek uniemożliwia zatwierdzenie transakcji, może to spowodować pojawienie się blokady.
Na przykład, jeśli baza danych jest synchronicznie dublowana, transakcja nie może zatwierdzić i zwolnić blokad, dopóki rekordy dziennika nie zostaną przesłane do serwera lustrzanego i zapisane na dysku dziennika serwera lustrzanego. Jeśli sieć jest mocno przeciążona lub istnieje duża rywalizacja we/wy na serwerze lustrzanym, może to poważnie opóźnić operację dublowania, a zatem spowodować, że zatwierdzenie transakcji będzie trwało znacznie dłużej. Wyglądałoby to na blokowanie, ale główną przyczyną jest rywalizacja o zasoby związane z tworzeniem kopii lustrzanych.
Blokowanie czeka, chyba że przyczyna jest oczywista, patrząc na plan zapytania, zablokuj zasób (np. poziom tabeli wskazujący eskalację blokady lub poziom izolacji, postępuj zgodnie z łańcuchem blokowania (używając skryptu, który przechodzi przez kolumnę blocking_session_id w sys.dm_exec_requests, a następnie spójrz, aby zobaczyć, na co czeka wątek na początku łańcucha blokowania. Wskazuje to na główną przyczynę.
ASYNC_NETWORK_IO
Nazwa tego powoduje wiele zamieszania. Na jakim słowie się skupiasz? SIEĆ. Przyczyna tego typu oczekiwania zwykle nie ma nic wspólnego z siecią. Powinien nazywać się WAITING_FOR_APP_ACK (nowledgment) lub podobnie, ponieważ dokładnie tak się dzieje:SQL Server wysłał pewne dane do klienta i czeka, aż klient potwierdzi, że dane zostały zużyte.
Jednym z moich ulubionych pokazów, które należy wykonać podczas nauczania o statystyce oczekiwania, jest uruchomienie zapytania, które zwraca duży zestaw wyników w Management Studio i obserwowanie, jak serwer czeka na ASYNC_NETWORK_IO. Oczywiście nie jest zaangażowana żadna sieć — po prostu SSMS zajmuje dużo czasu, aby odpowiedzieć na SQL Server. Robi to, co jest znane jako RBAR (Row-By-Agonizing-Row), gdzie tylko jeden wiersz na raz jest pobierany z wyników i przetwarzany, zamiast buforować wszystkie wyniki, a następnie natychmiast odpowiadać na SQL Server i przechodzić do przetwarzania buforowane wiersze.
Jest to główna przyczyna czekania ASYNC_NETWORK_IO – słaby projekt aplikacji. Następnie sprawdziłbym, czy serwer, na którym działa kod aplikacji, ma problem z wydajnością, nawet jeśli sam kod aplikacji jest dobrze zaprojektowany. Czasami jest to sieć, ale z mojego doświadczenia wynika, że jest to rzadkie.
OLEDB
Powszechną reakcją odruchową jest utożsamienie tego typu oczekiwania z serwerami połączonymi. Jednak ten czas oczekiwania stał się bardziej powszechny po wydaniu SQL Server 2005, ponieważ 2005 zawierał mnóstwo nowych DMV, a DMV głównie używa OLE DB pod osłonami. Zanim poszukam problemów z połączonym serwerem, sprawdziłbym, czy narzędzie monitorujące stale uruchamia DMV na serwerze.
Jeśli masz serwery połączone, kontynuuj rozwiązywanie problemów, przechodząc do serwera połączonego i sprawdzając tam statystyki oczekiwania, aby zobaczyć, jaki jest najbardziej rozpowszechniony problem, a następnie kontynuuj tę samą analizę.
Inną rzeczą, która może powodować oczekiwanie OLEDB, jest DBCC CHECKDB (i powiązane polecenia). Używa zestawu wierszy OLE DB do przekazywania informacji między podsystemami procesora zapytań i silnika pamięci masowej.
Inne oczekiwania
Niektóre inne oczekiwania, które powodują odruchy kolanowe, to CXPACKET, PAGEIOLATCH_XX, SOS_SCHEDULER_YIELD i WRITELOG. Omówię je w moim poście w przyszłym miesiącu.
Podsumowanie
Jeśli masz problem z wydajnością, poświęć trochę czasu na zrozumienie danych, na które patrzysz, i przeprowadź dalsze badania, aby zawęzić się do głównej przyczyny problemu. Nie chwytaj się tylko tego, co wydaje się być najlepszymi statystykami oczekiwania i postępuj zgodnie z pierwszą radą, którą napotkasz w Internecie (chyba że pochodzi ona z dobrze znanego i renomowanego źródła), w przeciwnym razie prawdopodobnie nie rozwiążesz swojego problemu, a może nawet pogorszyć sytuację.
Jeśli chodzi o ogólne statystyki oczekiwania, więcej informacji na temat ich używania do rozwiązywania problemów z wydajnością znajdziesz w:
- Moja seria postów na blogu, 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
Był to pierwszy z serii wpisów, które będę robił w ciągu tego roku, w których będzie mowa o odruchowych (re)akcjach związanych z SQL Server io tym, dlaczego są one niewłaściwe. Miłego rozwiązywania problemów do następnego razu!
