Jeśli użytkownicy Twojej bazy danych narzekają, że ostatnio wydajność programu SQL Server jest niska, możliwe, że doświadczasz skutków jednego lub większej liczby wąskich gardeł programu SQL Server. Te wąskie gardła występują z różnych powodów, ale często są wynikiem problemów z pamięcią, we/wy lub procesorem.
Chociaż nie zawsze łatwo jest określić, czy problemy z wydajnością wynikają z wąskiego gardła programu SQL Server, czy z innego źródła, można poszukać tych typowych objawów wąskich gardeł, aby zawęzić wyszukiwanie źródła problemu.
Typowe objawy wąskich gardeł w SQL Server
- SQL Server obciąża procesor
- Dłuższe czasy wykonywania zapytań
- Nadmierna liczba we/wy
- Dziennik aplikacji pokazujący komunikaty o braku pamięci
- Ekstremalna aktywność na dyskach
- Długie czasy oczekiwania na wejście/wyjście
Nagłe pojawienie się jednego lub więcej z tych symptomów jest dobrą wskazówką, że gdzieś w systemie występuje wąskie gardło programu SQL Server. Teraz Twoim zadaniem jest go znaleźć.
Rodzaje wąskich gardeł w SQL Server
Istnieją trzy główne typy wąskich gardeł programu SQL Server:pamięć, operacje we/wy i procesor. Ważne jest, aby administratorzy baz danych byli zaznajomieni z przyczynami, objawami i poprawkami każdego z nich, aby mogli szybko zidentyfikować i usunąć wąskie gardła oraz zminimalizować wpływ niskiej wydajności. Dołączyliśmy również jedne z najlepszych liczników wydajności do monitorowania, które pomogą natychmiast zidentyfikować wąskie gardła wydajności.
Wąskie gardła pamięci
Wąskie gardła pamięci są zwykle wynikiem niewystarczających zasobów pamięci lub działań programu SQL Server pochłaniających dostępną pamięć. Objawy, na które należy zwrócić uwagę, obejmują dłuższe czasy wykonywania zapytań, nadmierne operacje we/wy, komunikaty o braku pamięci w dzienniku aplikacji i częste awarie systemu.
Najlepszym sposobem na uniknięcie wąskich gardeł związanych z pamięcią jest użycie optymalizatora zapytań w celu pozbycia się niepotrzebnych lub przestarzałych zapytań oraz skonfigurowanie oczekiwanej długości życia strony w połączeniu ze współczynnikiem trafień w pamięci podręcznej bufora w celu ograniczenia podróży na dysk. Jeśli jest już za późno, aby uniknąć wąskiego gardła, spróbuj przejrzeć i dostroić zapytania, ponownie skonfigurować pamięć lub dodać pamięć fizyczną.
Liczniki do monitorowania:dostępna pamięć, całkowita pamięć serwera, pamięć serwera docelowego, strony/s, współczynnik trafień w buforze pamięci podręcznej
Wąskie gardła we/wy
Gdy nie ma wystarczającej ilości dostępnego magazynu do obsługi regularnych operacji bazy danych, takich jak TempDB, prawdopodobnie wystąpią wąskie gardła we/wy. Długie czasy odpowiedzi, spowolnienia aplikacji i częste przerwy w wykonywaniu zadań to kluczowe wskaźniki, że masz wąskie gardło we/wy.
Tego typu wąskich gardeł można uniknąć, konfigurując monitorowanie z alarmami i alertami progowymi, aby określić, które działania wykorzystują nadmierne ilości pamięci. Jeśli wystąpi wąskie gardło we/wy, ogranicz odczytywanie i zapisywanie stron bazy danych na iz dysku. Będzie to wymagało sprawdzenia i poprawienia częstych skanów indeksów, nieefektywnych zapytań i nieaktualnych statystyk.
Liczniki do monitorowania:średnia długość kolejki dysku, średnia s/odczyt dysku, średnia s/zapis dysku, % czasu dysku, średni odczyt dysku/s, średnia liczba zapisów na dysku/s
Wąskie gardła procesora
Główną przyczyną wąskich gardeł procesora jest niewystarczające zasoby sprzętowe. Dość łatwo jest zidentyfikować to wąskie gardło, sprawdzając dzienniki, aby określić, czy SQL Server zużywa zbyt dużo procesora.
W idealnym świecie można by uniknąć wąskich gardeł procesora, mając dedykowany serwer tylko dla SQL Server i uruchamiając całe inne oprogramowanie na innej maszynie. Ponieważ nie jest to opcja dla większości administratorów baz danych, musisz wiedzieć, jak odblokować procesor.
Pierwszym krokiem jest identyfikacja wieprzów procesora. Gdy już wiesz, gdzie leży problem, możesz dostroić zapytania, ulepszyć plany wykonania lub przekonfigurować system.
Liczniki do monitorowania:% czasu procesora, żądania wsadowe/s, kompilacje SQL/s, rekompilacje SQL/s
Opowieść na temat wąskich gardeł wydajności SQL Server
„Musimy sobie poradzić z pewnymi wąskimi gardłami w wydajności SQL Server” — powiedział mój szef pewnego piątku.
"Skąd wiesz?" – zapytałem.
„Sprzedaż skarży się, że ich baza danych ostatnio zwalnia. Musimy zobaczyć, co się z nim dzieje”.
"OK. Zarezerwuję salę konferencyjną, abyśmy mogli usiąść i nad tym popracować”.
„Nie kłopocz się” – powiedział szef. „Jest późne piątkowe popołudnie. Oznacza to, że najlepszym sposobem na zbadanie wąskich gardeł jest kilku naszych. Idziemy do Pike Pub na rynku”.
Weszliśmy do baru schowanego w Pike Place Market i znaleźliśmy mały stolik przy oknie.
„Jaki jest twój ulubiony rodzaj wąskiego gardła?” – zapytał szef.
Powiedziałem, że mam słabość do Naughty Nellie w wąskim gardle o wadze 22 uncji.
„Dobry wybór”, powiedział szef. „Zamów to, a ja zjem Citrus Summer Ale”.
Czekając na pojawienie się wąskich gardeł, zabraliśmy się do pracy nad wąskimi gardłami wydajności SQL Server.
„Będziemy musieli sprawdzić problemy w kilku miejscach” – powiedział szef. „Mogą to być problemy z pamięcią, pamięcią masową lub procesorami, ale wszystkie wyglądają tak samo dla użytkowników, prawda? Kiepska wydajność.
„Problemy z procesorem nie są trudne do znalezienia. Jeśli na tym polega problem, zobaczymy, że SQL Server obciąża procesor i powoduje jego ciągłe skoki.
„Jeśli jest to problem z pamięcią, zobaczymy takie rzeczy, jak dłuższe czasy wykonywania zapytań i więcej operacji we/wy, ponieważ aplikacja musi cały czas wyczerpywać się na dysku. Możemy również sprawdzić dziennik aplikacji pod kątem komunikatów o braku pamięci.
„A jeśli wąskie gardło jest w pamięci, zobaczymy ekstremalną aktywność na dyskach i długi czas oczekiwania na wejście/wyjście”.
Pojawiły się nasze wąskie gardła. Przestudiowaliśmy je uważnie, głębiej rozważając problem z wydajnością.
Wiele potencjalnych źródeł wąskich gardeł wydajności SQL Server
„A co, jeśli jest to problem we/wy?” Zapytałam. „Powinniśmy sprawdzić, czy czas oczekiwania WRITELOG nie jest zbyt długi w porównaniu z całkowitym czasem oczekiwania. Albo mówiąc o I/O, może problem tkwi w samym SQL. Jeśli istnieje niewydajny kod, taki jak ŁĄCZENIE PĘTLI ZAGĘSZCZONEJ w ogromnej tabeli, SQL może prosić o odczytanie wierszy z tabeli wewnętrznej miliony razy. To naprawdę ukarałoby wydajność”.
„Może być”, powiedział szef. „Złożone łączenia i operacje sortowania mogą być trudne, zwłaszcza gdy baza danych tempdb nie jest poprawnie skonfigurowana. Rywalizacja o Tempdb wygląda jak zwykłe blokady bazy danych, ale w rzeczywistości jest to rywalizacja z blokadą, ponieważ wszystkie współbieżne procesy czekają na swoją kolejkę na stronach alokacji”.
„Których narzędzi możemy użyć do zbadania tych wszystkich rzeczy?” – zapytałem.
„SQL Server miał profiler do badania procedur składowanych, ale jest przestarzały. Coś takiego jest dobrym sposobem na znalezienie i zdiagnozowanie zapytań problemowych, nawet jeśli to dopiero pierwszy krok. Dostępne są też dynamiczne widoki i funkcje zarządzania, które pomagają monitorować stan serwera i bazy danych, rozwiązywać problemy i dostrajać SQL”.
„Ale SQL Server ma tak wiele ruchomych części”, powiedziałem. „Wolałbym mieć narzędzie, które patrzy na cały obraz z zewnątrz”.
„Ja też. Najlepiej z chmury, więc nie potrzebujemy do tego więcej sprzętu i oprogramowania na miejscu”.
Uwalnianie wąskich gardeł wydajności w SQL Server
Pike robił się zatłoczony. I tak chętnie jak szef i ja mieliśmy siedzieć w pubie i rozmawiać, w końcu był piątek wieczorem. Mieliśmy inne miejsca do odwiedzenia, inne osoby do zobaczenia i inne rzeczy do omówienia.
„Co powinniśmy zrobić, gdy już znajdziemy wąskie gardła?” – zapytałem.
„Zbieramy zwykłych podejrzanych”, powiedział szef. „Aby nie używać zbyt dużej ilości pamięci, musimy poinformować programistów baz danych, który z ich kodu i zapytań powoduje wycieki pamięci. Jeśli znajdziemy operacje, które łączą cztery, pięć lub sześć tabel, będziemy musieli podać programistom kilka wskazówek dotyczących dostrajania SQL Server i najlepszych praktyk, aby przeprojektować bazę danych. Lub możemy mieć zbyt wiele indeksów i możemy marnować cykle na ich aktualizowanie; jest to tak trudne dla procesora i we/wy, jak posiadanie zbyt małej liczby indeksów. Możemy mieć problem z fragmentacją indeksu SQL Server lub możemy być zmuszeni do usunięcia przestarzałych i zduplikowanych indeksów”.
– To ma sens – powiedziałem. „Może musimy dołożyć do tego więcej sprzętu. Szybsze dyski mogą pomóc w przypadku wąskich gardeł we/wy. Coraz szybsze procesory mają wpływ na czasy odpowiedzi na zapytania. A dodanie pamięci RAM oznacza większą skalowalność SQL Server, prawda?”
„Tak”, powiedział szef, „ale najpierw chcę się upewnić, że główną przyczyną nie jest problem z programowaniem lub DevOps. Gdy będę przekonany, że tak nie jest, zagram w kartę Kup więcej sprzętu”.
Siedzieliśmy przez chwilę i patrzyliśmy, jak pub wypełnia się piątkowymi biesiadnikami.
„Szefie”, zapytałem, „czy myślisz, że wszyscy ci ludzie wiedzą, jak beztrosko prowadzą egzystencję, bez ciężaru radzenia sobie z zablokowanymi sesjami, maksymalnym oczekiwaniem na I/O, oczekiwaną długością życia strony i współczynnikami trafień w bufor pamięci podręcznej?”
„To krzyż do dźwigania, prawda?” - odpowiedział szef. „Większość ludzi nie ma pojęcia, przez co przechodzimy. Dobrze, że z wąskimi gardłami wydajności SQL Server radzimy sobie tak cicho, z tak dużą gracją pod presją iw tak dobrym guście. Mówiąc o dobrym guście, jak sobie radzisz z wąskim gardłem?”
Sprawdziłem. „Moje wąskie gardło jest puste. Moja butelka też”.
"Moje też. Czas iść. Mamy pracę do wykonania”.
Czy możliwy jest system zerowego wąskich gardeł SQL Server?
Wiemy, że istnieją kroki, które możemy podjąć, aby uniknąć tych trzech typowych typów wąskich gardeł programu SQL Server. Ale czy możliwe jest skonfigurowanie bazy danych SQL Server tak dobrze, że nie będzie miała żadnych wąskich gardeł?
Krótka odpowiedź prawdopodobnie nie. Nawet najbardziej pracowity administrator baz danych może od czasu do czasu wyskakiwać z wąskich gardeł programu SQL Server. Możesz jednak podjąć kroki, aby aktywnie unikać wąskich gardeł i minimalizować ich wpływ na wydajność. Na przykład Brent Ozar oferuje kilka świetnych wskazówek dotyczących monitorowania liczników Perfmon w celu dostrojenia SQL Server, a widok sys.dm_os_performance_counters umożliwia identyfikowanie wąskich gardeł i szybkie ich korygowanie.
Wąskie gardła programu SQL Server są nieodłącznym elementem DBA. Na szczęście, przy odpowiednim nadzorze, starannym monitorowaniu i częstym dostrajaniu zapytań, problemy z wydajnością można rozwiązać, zanim użytkownicy zorientują się, że istnieje problem.
