sys.dm_resource_governor_resource_pools pokazuje stan pul zasobów zdefiniowanych w Resource Governor.
Co pokazuje sys.dm_resource_governor_resource_pools
sys.dm_resource_governor_resource_pools jest widokiem dynamicznego zarządzania w Microsoft SQL Server. Zwraca bieżący stan pul zasobów utworzonych i używanych przez mechanizm Resource Governor. Pula zasobów jest obiektem, do którego SQL Server przypisuje obciążenia zaklasyfikowane przez funkcję klasyfikującą. Następnie ustawienia puli określają między innymi udział procesora, dostęp do pamięci oraz ograniczenia operacji wejścia i wyjścia. Widok nie opisuje pojedynczych zapytań. Pokazuje zagregowane informacje dotyczące całej puli.
Dane z tego widoku są przydatne podczas sprawdzania, czy skonfigurowane limity odpowiadają rzeczywistemu obciążeniu. Można na ich podstawie porównać pule używane przez różne grupy połączeń, sprawdzić wykorzystanie przydzielonej pamięci oraz ocenić, czy ograniczenia I/O powodują kolejki lub opóźnienia. Warto pamiętać, że jest to widok diagnostyczny prezentujący stan środowiska w momencie odczytu, a nie trwały dziennik wszystkich zdarzeń.
Najważniejsze informacje o stanie puli
Wiersz widoku identyfikuje pulę między innymi przez wartości pool_id i name. Kolumny związane z procesorem obejmują min_cpu_percent, max_cpu_percent oraz cap_cpu_percent. Minimalny i maksymalny udział CPU opisuje zakres udziału, jaki Resource Governor może zapewnić grupie obciążeń w ramach wewnętrznego planowania zasobów. Limit cap_cpu_percent określa górną granicę wykorzystania procesora przez pulę. Wartości te nie zmieniają częstotliwości taktowania procesora i nie są odpowiednikiem ustawień systemu operacyjnego.
Informacje pamięciowe obejmują między innymi min_memory_percent, max_memory_percent, max_memory_kb, used_memory_kb oraz target_memory_kb. used_memory_kb wskazuje ilość pamięci używaną przez pulę, natomiast target_memory_kb przedstawia docelową ilość pamięci wyznaczoną przez silnik. memory_denied_count pozwala zauważyć przypadki, w których żądania pamięci nie zostały przyznane, a active_memgrant_count i memgrant_waiter_count pokazują odpowiednio liczbę aktywnych przydziałów pamięci oraz oczekujących wniosków. Wysokie wartości oczekujących przydziałów mogą wskazywać na presję pamięci, ale wymagają zestawienia z obciążeniem zapytań i innymi licznikami SQL Server.
Odczyt danych i interpretacja ograniczeń I/O
Widok może także prezentować statystyki operacji odczytu i zapisu przypisanych do puli. Dostępne liczniki obejmują między innymi liczbę operacji zakolejkowanych, wydanych, ukończonych i ograniczonych przez Resource Governor, a także liczbę przetworzonych bajtów. Dla operacji odczytu i zapisu występują osobne grupy liczników, dlatego nie należy traktować pojedynczej wartości jako pełnego obrazu wydajności dysku. Istotne są relacje między liczbą żądań, liczbą operacji throttled oraz wielkością danych.
Jeżeli w puli skonfigurowano max_iops_per_volume, SQL Server może ograniczać liczbę operacji wejścia i wyjścia kierowanych do pojedynczego woluminu. Liczniki read_io_throttled_total i write_io_throttled_total pomagają stwierdzić, czy takie ograniczenie faktycznie zadziałało. io_issue_delay_ms wskazuje skumulowany czas opóźnień związanych z wydawaniem operacji I/O. Nie jest to bezpośredni pomiar czasu odpowiedzi konkretnego dysku ani pojedynczego zapytania. Statystyki należy interpretować razem z metrykami systemu operacyjnego, wydajnością plików danych i dziennika transakcji oraz planami wykonania obciążających instrukcji.
Przykładowe zapytanie diagnostyczne może ograniczyć wynik do najważniejszych ustawień i bieżącego zużycia:
SELECT pool_id, name, min_cpu_percent, max_cpu_percent, cap_cpu_percent, used_memory_kb, target_memory_kb, memory_denied_count, active_memgrant_count, memgrant_waiter_count FROM sys.dm_resource_governor_resource_pools;
Znaczenie widoku w diagnostyce SQL Server
Sam odczyt DMV nie zmienia konfiguracji Resource Governor i nie przełącza stanu puli. Służy do obserwacji działania już zdefiniowanych ustawień. Podczas analizy należy najpierw ustalić, jakie workload groups są przypisane do danej puli i jaka funkcja klasyfikująca kieruje połączenia do tych grup. Dopiero wtedy można powiązać widoczne zużycie CPU, pamięci lub I/O z konkretnymi typami obciążenia. Pula może mieć wysokie wykorzystanie zasobów dlatego, że obsługuje wiele sesji, albo dlatego, że kilka zapytań wykonuje kosztowne operacje równolegle.
W praktyce szczególnie ważne jest rozróżnienie pomiędzy konfiguracją limitu a rzeczywistym problemem wydajnościowym. Niski limit CPU może być zamierzonym sposobem ochrony obciążenia priorytetowego, ale może też powodować oczekiwanie zadań w puli. Wysoki memgrant_waiter_count może wynikać z dużych sortowań lub operacji hash, a nie z błędnej wartości limitu pamięci. Rosnące liczniki I/O ograniczonego przez Resource Governor wskazują na działanie mechanizmu kontroli, lecz nie przesądzają, że nośnik jest uszkodzony. Rzetelna diagnostyka SQL Server powinna obejmować porównanie DMV w kilku punktach czasu, analizę zapytań, sesji i grup obciążeń oraz sprawdzenie konfiguracji plików baz danych.
