Resource Group

Resource Group to zbiór sesji objętych wspólnym limitem zasobów w ramach Resource Governor.

Resource Group w Resource Governor — czym jest i do czego służy

Resource Group to logiczna grupa obciążeń utworzona w mechanizmie Resource Governor, czyli funkcji służącej do kontrolowania sposobu wykorzystywania zasobów przez różne sesje i zadania bazy danych. Do jednej grupy przypisuje się połączenia, które powinny podlegać podobnym zasadom działania. Dzięki temu można oddzielić obciążenia wymagające szybkiej reakcji od procesów wykonywanych w tle, raportów, importów danych albo zadań administracyjnych.

Sama grupa nie jest użytkownikiem, rolą, bazą danych ani osobnym procesem systemowym. Stanowi warstwę organizacyjną, do której przyporządkowuje się sesje na podstawie zdefiniowanych kryteriów. Po zaklasyfikowaniu połączenia do wybranej grupy stosowane są parametry ustalone dla tej grupy, na przykład dotyczące udziału procesora, pamięci, współbieżności lub czasu oczekiwania na określone zasoby.

W praktyce Resource Group pomaga opisać oczekiwany sposób obsługi danego rodzaju pracy. Jedna grupa może obejmować operacje interaktywne, które powinny sprawnie odpowiadać na żądania użytkownika, a inna może gromadzić długotrwałe zapytania analityczne. W ten sposób można ograniczyć wzajemne oddziaływanie różnych obciążeń i łatwiej przewidzieć zachowanie systemu w okresach większej aktywności.

Resource Group a pule zasobów, klasy obciążenia i priorytety

Warto odróżnić Resource Group od puli zasobów. Pula określa dostępny zakres zasobów oraz reguły, według których może on być wykorzystywany. Grupa wskazuje natomiast, które sesje mają podlegać danym regułom. Najprościej ująć to jako relację pomiędzy opisem obciążenia a sposobem jego obsługi: grupa porządkuje połączenia, a konfiguracja Resource Governor określa konsekwencje takiego przyporządkowania.

Resource Group nie działa również jak zwykły priorytet nadawany pojedynczemu zapytaniu. Klasyfikacja jest wykonywana dla sesji lub połączenia, dlatego jej skutki mogą obejmować wiele kolejnych operacji realizowanych w ramach danego kontekstu. Z tego powodu należy zwracać uwagę na sposób identyfikowania połączeń, wykorzystane konta, aplikacje klienckie oraz właściwości sesji. Błędna klasyfikacja może spowodować, że ograniczenia zostaną zastosowane do niewłaściwego rodzaju pracy.

Przy projektowaniu grup przydatne jest porównanie kilku wymiarów obciążenia. Znaczenie może mieć długość zapytań, częstotliwość ich uruchamiania, wrażliwość użytkownika na opóźnienia, zapotrzebowanie na pamięć, charakter operacji wejścia i wyjścia oraz to, czy dane zadanie działa regularnie, czy tylko okresowo. Nie powinno się tworzyć grup wyłącznie według nazw użytkowników, jeśli faktyczny sposób pracy różni się w zależności od aplikacji lub procesu.

Ważna jest także kolejność reguł klasyfikujących. Jeżeli kilka warunków może pasować do tej samej sesji, wynik zależy od przyjętego mechanizmu rozstrzygania. Przed wdrożeniem warto opisać oczekiwany rezultat dla typowych połączeń i sprawdzić, czy każde z nich trafia do właściwej grupy. Pomocne bywa przygotowanie tabeli obejmującej nazwę aplikacji, konto, rodzaj zadania, przewidywane obciążenie oraz docelową grupę.

Resource Group przy typowych problemach z wydajnością

Jednym z częstych problemów jest sytuacja, w której raport uruchomiony w godzinach aktywnej pracy zużywa znaczną część dostępnych zasobów. Objawem może być wolniejsze wykonywanie operacji, wydłużone oczekiwanie na odpowiedź albo chwilowe przeciążenie. Przypisanie raportów do odpowiednio skonfigurowanej grupy może pomóc ograniczyć wpływ takiego zadania na pozostałe połączenia, choć nie zastępuje analizy zapytań, indeksów ani planów wykonania.

Inny przypadek dotyczy importów i eksportów danych. Proces działający przez dłuższy czas może konkurować o pamięć i czas procesora z operacjami wykonywanymi przez użytkowników. Wydzielenie takich połączeń do osobnej Resource Group ułatwia nadanie im przewidywalnych ograniczeń. Trzeba jednak sprawdzić, czy ograniczenie nie wydłuży procesu do poziomu, przy którym zadanie zacznie kolidować z kolejnym oknem przetwarzania.

Problemy mogą wynikać także z nieprawidłowego rozpoznawania sesji. Jeśli reguła klasyfikacji opiera się na nazwie aplikacji, a aplikacja nie przekazuje tej wartości konsekwentnie, połączenia mogą trafiać do grupy domyślnej. Podobna sytuacja występuje wtedy, gdy wspólne konto jest używane przez zadania o różnym charakterze. W takim przypadku trzeba zweryfikować dostępne atrybuty sesji i rozważyć bardziej precyzyjny sposób rozdzielenia obciążeń.

Nie każdy spadek wydajności oznacza problem z limitem zasobów. Przyczyną może być blokowanie transakcji, brak odpowiedniego indeksu, fragmentacja danych, nieaktualne statystyki, błędny plan wykonania, problemy z pamięcią operacyjną albo niewłaściwa konfiguracja systemu. Resource Group ogranicza skutki konkurencji pomiędzy obciążeniami, ale nie naprawia wadliwej logiki zapytań i nie usuwa przyczyn uszkodzeń sprzętowych.

Resource Group — praktyczne wskazówki dotyczące konfiguracji

Konfigurację najlepiej rozpoczynać od pomiarów. Należy ustalić, które sesje są najczęściej uruchamiane, jakie zasoby wykorzystują i w jakich momentach pojawiają się opóźnienia. Przydatne są dzienniki, statystyki wydajności oraz obserwacja obciążenia przed i po zmianie ustawień. Bez pomiarów łatwo wprowadzić ograniczenia, które tylko przesuną problem w inne miejsce.

Nazwa grupy powinna jasno wskazywać jej przeznaczenie. Określenia odnoszące się do raportów, zadań wsadowych, operacji użytkownika lub procesów utrzymaniowych są zwykle bardziej użyteczne niż nazwy techniczne pozbawione kontekstu. Warto także prowadzić opis właściciela grupy, kryteriów klasyfikacji, obowiązujących parametrów oraz powodów wprowadzenia konfiguracji.

Zmiany należy wprowadzać etapami. Najpierw można utworzyć grupę i obserwować, jakie sesje są do niej przypisywane, a dopiero później zastosować bardziej restrykcyjne ustawienia. Po każdej zmianie powinno się sprawdzić czas odpowiedzi, liczbę oczekujących operacji, zużycie procesora, wykorzystanie pamięci oraz zachowanie zadań wykonywanych cyklicznie. W przypadku niepożądanych skutków przydatny jest wcześniej opisany wariant powrotu do poprzedniej konfiguracji.

Nie należy mnożyć grup bez wyraźnej potrzeby. Zbyt szczegółowy podział utrudnia utrzymanie reguł i może sprawić, że podobne obciążenia będą traktowane odmiennie bez uzasadnienia. Lepszy efekt daje kilka dobrze opisanych grup, których zasady są zrozumiałe dla osób odpowiedzialnych za administrację i analizę wydajności.

Warto również pamiętać o uprawnieniach i zmianach w środowisku. Dodanie nowej aplikacji, zmiana konta używanego przez zadanie albo aktualizacja sposobu nawiązywania połączeń może wpłynąć na wynik klasyfikacji. Po takich zmianach wskazane jest ponowne sprawdzenie, czy sesje nadal trafiają do właściwych grup.

Resource Group — kiedy zgłosić się do serwisu komputerowego

Do serwisu warto zgłosić się wtedy, gdy problemy przypisywane Resource Group występują razem z zawieszaniem aplikacji, nagłymi restartami, przegrzewaniem, błędami pamięci masowej albo niestabilnym działaniem komputera. W takich przypadkach sama konfiguracja bazy danych może być tylko częścią większego problemu. Potrzebna może być kontrola podzespołów, nośnika danych, pamięci operacyjnej, systemu oraz sposobu chłodzenia.

Warszawskie Pogotowie Komputerowe 24/7 zajmuje się diagnostyką i naprawą laptopów oraz komputerów PC, dlatego można przekazać do oceny urządzenie, na którym występują opisane objawy. Przed rozpoczęciem prac warto przygotować informacje o momencie pojawiania się problemu, ostatnich zmianach w konfiguracji, komunikatach błędów oraz aplikacjach uruchamianych w tym czasie. Takie dane ułatwiają rozdzielenie problemu sprzętowego od błędu ustawień lub oprogramowania.

W przypadku środowiska korzystającego z Resource Governor przydatne jest również zachowanie fragmentów dzienników, informacji o obciążeniu i opisu wykonanych zmian. Pozwala to sprawdzić, czy źródłem trudności jest niewłaściwa klasyfikacja sesji, nadmierne ograniczenie zasobów, problem z zapytaniem, czy usterka komputera. Dopiero po takim rozróżnieniu można dobrać właściwy sposób dalszego postępowania.