sys.dm_server_memory to zbiorcze określenie widoków opisujących wykorzystanie pamięci przez instancję.
Co obejmuje określenie sys.dm_server_memory w SQL Server
sys.dm_server_memory nie jest pojedynczym widokiem dynamicznego zarządzania dostępnym w SQL Server pod taką nazwą. To zbiorcze określenie grupy widoków DMV, których dane pozwalają przeanalizować pamięć używaną przez instancję SQL Server oraz jej relację do pamięci systemu operacyjnego. W praktyce podczas diagnostyki sprawdza się między innymi sys.dm_os_process_memory, sys.dm_os_sys_memory, sys.dm_os_memory_clerks, sys.dm_os_memory_nodes i sys.dm_os_memory_cache_counters. Każdy z tych widoków opisuje inny poziom działania silnika, dlatego pojedyncza kolumna nie powinna być traktowana jako pełny pomiar całkowitego zużycia pamięci.
Widoki DMV dotyczą bieżącego stanu uruchomionej instancji. Ich zawartość może zmieniać się podczas pracy obciążenia, po wykonaniu zapytań, po zwolnieniu pamięci przez system albo po zmianie konfiguracji. Wnioski trzeba więc odnosić do czasu wykonania zapytania i, przy problemach okresowych, porównywać z kolejnymi pomiarami. Dostęp do części informacji zależy od uprawnień administracyjnych, a w nowszych wersjach SQL Server wymagane uprawnienia mogą różnić się między poszczególnymi DMV.
Rozdzielenie pamięci procesu, systemu i obszarów silnika
sys.dm_os_process_memory pokazuje informacje o pamięci przypisanej procesowi SQL Server, w tym między innymi rozmiar pamięci procesu, pamięć zadeklarowaną przez proces oraz stan presji pamięci wykrywanej na poziomie procesu. sys.dm_os_sys_memory opisuje pamięć widzianą z perspektywy systemu operacyjnego, na przykład całkowitą pamięć fizyczną, pamięć dostępną i stan presji pamięci systemowej. Te dwa widoki odpowiadają na różne pytania: pierwszy dotyczy procesu SQL Server, a drugi całego hosta. Wysokie zużycie pamięci procesu nie dowodzi samo w sobie awarii, ponieważ SQL Server wykorzystuje pamięć do przechowywania danych, planów zapytań i struktur roboczych.
sys.dm_os_memory_clerks pozwala rozbić pamięć według tak zwanych memory clerks, czyli wewnętrznych komponentów odpowiedzialnych za rezerwowanie i śledzenie pamięci. Kolumny takie jak pages_kb, virtual_memory_committed_kb i shared_memory_committed_kb opisują różne kategorie alokacji i nie powinny być bezrefleksyjnie sumowane jako jeden równoważny licznik. Przykładowo pamięć buforów danych, pamięć kompilacji, pamięć zapytań i pamięć rozszerzeń może pojawiać się w innych clerkach. Analiza nazwy type oraz kilku kategorii jednocześnie jest dokładniejsza niż wskazanie największej pojedynczej wartości.
Jak czytać sygnały presji pamięci
Presja pamięci oznacza, że SQL Server lub system operacyjny sygnalizuje ograniczoną dostępność zasobów. W diagnostyce należy odróżnić presję wewnętrzną, dotyczącą zapotrzebowania komponentów SQL Server, od presji zewnętrznej, wynikającej z małej ilości pamięci dostępnej dla całego systemu. Przydatne są do tego między innymi kolumny stanu w sys.dm_os_process_memory i sys.dm_os_sys_memory, a także widoki liczników oczekiwania na pamięć, takie jak sys.dm_os_memory_cache_counters oraz sys.dm_os_performance_counters. Sam fakt, że system używa dużej części RAM jako pamięci podręcznej, nie oznacza jeszcze presji.
Ważne jest także rozróżnienie pamięci przydzielonej od pamięci faktycznie używanej przez konkretny komponent. Wartości obserwowane w DMV mogą obejmować pamięć zarezerwowaną, zatwierdzoną, używaną przez struktury buforowe albo przeznaczoną na obiekty cache. Jeżeli zapytania zwalniają po wzroście obciążenia, należy zestawić dane pamięci z aktualnie wykonywanymi żądaniami, oczekiwaniami typu RESOURCE_SEMAPHORE, rozmiarem puli buforów i konfiguracją max server memory. Ograniczenie tej wartości może być zasadne, gdy system współdzieli RAM z innymi procesami, ale ustawienie jej bez pomiarów może zmniejszyć pamięć dostępną dla SQL Server.
Praktyczne wykorzystanie DMV przy diagnostyce instancji
Analizę warto rozpocząć od zapisania czasu pomiaru, wersji i edycji SQL Server oraz podstawowej konfiguracji pamięci. Następnie porównuje się stan procesu z pamięcią systemu operacyjnego, a później schodzi do poziomu memory clerks i węzłów pamięci z sys.dm_os_memory_nodes. Jeżeli jeden clerk rośnie znacznie szybciej niż pozostałe, trzeba powiązać go z funkcją silnika, zapytaniami lub komponentem używanym przez daną instancję. Jednorazowy odczyt nie rozstrzyga, czy wzrost jest prawidłowym rozgrzewaniem cache, reakcją na chwilowe zapytanie, czy niekontrolowanym przyrostem.
Przy serwisowej ocenie komputera lub serwera należy zebrać także informacje o dostępnej pamięci RAM, aktywności innych procesów, czasie wystąpienia spowolnienia i powtarzalności objawu. DMV opisują stan logiczny widziany przez SQL Server, lecz nie zastępują testu sprzętu, monitorowania systemu operacyjnego ani analizy konfiguracji konkretnej instancji. Rzetelna diagnoza polega na korelacji kilku pomiarów: presji pamięci, zajętości według clerków, oczekiwań zapytań, konfiguracji limitu pamięci oraz zmian obserwowanych w czasie. Dzięki temu można odróżnić normalne wykorzystanie pamięci przez SQL Server od rzeczywistego problemu z zasobami.
