Metryka oczekiwana długość życia strony programu SQL Server (PLE) od dawna jest uważana za kluczowy wskaźnik wydajności dla administratorów baz danych, patrząc na ogólną kondycję ich instancji baz danych. PLE pokazuje, czy system jest pod napięciem pamięci wewnętrznej za pomocą liczników dostarczonych przez obiekt Buffer Manager.
Bliższe spojrzenie na długość życia strony
PLE jest miarą czasu (w sekundach), przez który strona pliku danych powinna pozostawać w puli buforów SQL Server. Ta metryka nie jest agregacją ani akumulacją, ale po prostu wartością punktu w czasie, o którą administratorzy baz danych będą wysyłać zapytania z Menedżera buforów.
SQL Server odczytuje tylko strony danych z puli buforów (tj. odczyt logiczny), więc jeśli strona nie znajduje się w puli buforów, znajduje ją na dysku (tj. odczyt fizyczny) i przenosi stronę do puli buforów, aby może wykonać logiczny odczyt. Jest to czasochłonny proces i może negatywnie wpłynąć na wydajność.
Co to jest „dobra” wartość PLE?
Wysoka wartość PLE oznacza, że strona dłużej pozostaje w puli buforów, więc SQL Server jest mniej prawdopodobne, że będzie musiał przejść na dysk w poszukiwaniu strony danych, co sprawia, że system działa szybciej.
Historycznie, administratorzy baz danych uważali 300 sekund (pięć minut) za najlepszy punkt PLE. Jednak ta liczba jest dość arbitralna. Microsoft zalecił 300 jako standard PLE w 2000 roku, kiedy pamięć była ograniczona.
Obecnie administratorzy baz danych nie skupiają się na „właściwej” liczbie, ponieważ w większości systemów standardem są zasobniki pamięci. Nie jest niczym niezwykłym, że SQL Server działa w systemie, który ma do dyspozycji TB pamięci RAM, więc administratorzy baz danych przyjęli standardowe podejście do identyfikacji „dobrej” wartości PLE:
Oczekiwana żywotność strony =300 sekund na każde 4 GB pamięci RAM na serwerze
Jednak prawdopodobnie ważniejsze jest ciągłe monitorowanie wartości PLE pod kątem zmian w spójności, dzięki czemu można zidentyfikować problemy z pamięcią i szybko je rozwiązać.
Jeśli pracujesz z dużą ilością danych, ważne jest, aby pamiętać, że większe serwery często mają wiele PLE. Każdy węzeł niejednorodnego dostępu do pamięci (NUMA) otrzymuje własną wartość PLE, a następnie te liczby są obliczane w celu uzyskania wartości PLE serwera. Na przykład weź wartość PLE węzła x 1000 (zrób to dla wszystkich węzłów NUMA). Dodaj wartości wszystkich węzłów, następnie podziel przez całkowitą liczbę węzłów NUMA, a następnie ponownie podziel przez 1000. To da ci serwer PLE.
Jak określić, czy występuje problem z oczekiwaną długością życia strony
Wahania w PLE są normalne, ponieważ są oparte na obciążeniu pracą. Śledzenie wysokich, średnich i niskich trendów może pokazać, czy niektóre procesy, takie jak skanowanie tabel lub opróżnianie pamięci podręcznej bufora, wymagają dostrojenia w celu ulepszenia PLE.
Dobrym sposobem określenia, czy jest problem, jest to, czy normalny zakres wartości PLE spada i pozostaje niski. Wskazuje to, że prawdopodobnie istnieje zwiększone zapotrzebowanie i presja na pulę buforów.
Czy to oznacza, że musisz poświęcić trochę więcej pamięci na problem? Być może. Może nie.
Rozwiązywanie problemów z niską oczekiwaną żywotnością strony programu SQL Server
Istnieje kilka powodów, dla których wartości PLE mogą mieć tendencję spadkową. Ważne jest, aby rozwiązać problem, ponieważ rozwiązanie nie jest takie samo dla każdej przyczyny źródłowej. Oto trzech sprawców, którzy najprawdopodobniej spowalniają Twoje PLE:
Niewystarczająca pamięć
Jeśli obciążenie pracą stale rośnie, a PLE maleje, prawdopodobnie brakuje Ci pamięci. Dodanie pamięci może pomóc w zwiększeniu PLE, ale nie sprawi, że zapytania będą działały wydajniej.
Drogie operacje
Jeśli obciążenie nie uległo zmianie, ale istnieje zwiększone zapotrzebowanie na pulę buforów, może to oznaczać, że wartości odstające zużywają więcej pamięci. Sprawdź, czy są uruchomione zadania konserwacji lub trwa odbudowa indeksu.
Nieaktualne statystyki
Nieaktualne statystyki mogą powodować zmiany w planie kwerend. Zwiększa to zapotrzebowanie na pulę buforów, powodując uruchamianie kosztownych operacji, ponieważ nie są one zsynchronizowane z nowymi statystykami.
Jak naprawić niską oczekiwaną długość życia strony, optymalizując zapytania
Najlepszym sposobem naprawienia niskich wartości PLE jest przejście do źródła i zoptymalizowanie zapytań SQL Server. Zapewnia to dodatkową premię, ponieważ optymalizacja zapytań poprawi jednocześnie ogólną wydajność systemu.
Jest kilka rzeczy, które chcesz zrobić, które pomogą Ci zoptymalizować zapytania w celu maksymalnego ulepszenia PLE:
- Upuść nieużywane indeksy
- Połącz zduplikowane indeksy
- Szukaj dużych zapytań
- Wiedz, co jest w puli buforów
- Defragmentuj indeksy
- Aktualizuj statystyki
- Wyczyść dane
Oczekiwana długość życia strony śledzenia w czasie
Chociaż PLE jest metryką z punktu w czasie, patrzenie na PLE w czasie jest ważnym sposobem wczesnego identyfikowania problemów i szybkiego ich rozwiązywania, zanim znacząco wpłynie to na wydajność.
Istnieje wiele sposobów monitorowania metryki PLE w czasie i identyfikowania zapytań, których transakcje powodują dużą liczbę odczytów. DMV i rozszerzone zdarzenia w SQL Server to wypróbowane i prawdziwe metody, które odegrały kluczową rolę w tym procesie gromadzenia danych. Ale są one również ręczne i czasochłonne oraz oferują ograniczone korzyści, jeśli chodzi o uzyskanie historycznej perspektywy na wydajność metryki w czasie.
Komercyjne rozwiązanie, takie jak Spotlight Cloud, nie tylko zapewnia administratorom baz danych możliwość śledzenia PLE w czasie od razu po wyjęciu z pudełka, ale także analizuje obciążenie, aby zidentyfikować, które zapytania i działania odstające wywierają presję na pulę buforów, dzięki czemu można izolować i korygować problem i zoptymalizuj wydajność serwera SQL.
Pierwotnie opublikowany w kwietniu 2019 r. i zaktualizowany we wrześniu 2020 r.
