SYS.DM_OS_SCHEDULERS

sys.dm_os_schedulers pokazuje stan harmonogramów wątków silnika bazodanowego.

Harmonogramy jako odwzorowanie rdzeni

Silnik SQL Server nie polega w pełni na planiście systemu operacyjnego, tylko prowadzi własny mechanizm kooperacyjnego przydziału czasu. Każdemu logicznemu procesorowi widocznemu dla instancji odpowiada jeden harmonogram o statusie VISIBLE ONLINE, obsługujący zapytania użytkowników. Obok nich istnieją harmonogramy ukryte, przeznaczone na zadania wewnętrzne, oraz osobny dedykowany połączeniu administracyjnemu — ten ostatni pozwala zalogować się do instancji nawet wtedy, gdy zwykłe sesje nie są w stanie dostać czasu procesora.

Kolumny, które faktycznie coś mówią

Najważniejsza jest runnable_tasks_count, czyli liczba zadań gotowych do pracy i czekających wyłącznie na procesor. Utrzymujące się wartości powyżej kilku na harmonogram to klasyczny obraz braku mocy obliczeniowej, a nie problemu z dyskiem. Obok niej current_tasks_count pokazuje wszystkie zadania przypisane do harmonogramu, łącznie z tymi czekającymi na zasoby, pending_disk_io_count sygnalizuje zaległe operacje wejścia-wyjścia, a load_factor służy silnikowi do rozdzielania nowych połączeń. Obraz z tego widoku warto zestawić z proporcją czasu oczekiwania na sygnał do całkowitego czasu oczekiwania, wyliczaną z widoku sys.dm_os_wait_stats — wysoki udział czasu sygnałowego potwierdza, że wątki czekają na dostęp do rdzenia, a nie na dane.

Błędne wnioski wyciągane z tego widoku

Pierwszy to porównywanie liczby harmonogramów z liczbą rdzeni fizycznych bez uwzględnienia, że instancja może mieć zawężoną maskę koligacji albo ograniczenie wynikające z edycji, przez co część rdzeni serwera jest po prostu niewidoczna dla silnika. Drugi to interpretowanie chwilowego skoku wartości jako problemu — widok pokazuje stan bieżący, więc pojedynczy odczyt w trakcie nocnego przebudowywania indeksów nic nie znaczy i potrzebne jest próbkowanie w czasie. Trzeci, najkosztowniejszy, to dokładanie rdzeni maszynie wirtualnej w reakcji na kolejkę zadań, podczas gdy prawdziwą przyczyną jest zapytanie bez indeksu skanujące całą tabelę albo nadmierne zrównoleglenie wymuszające udział wielu harmonogramów w jednym zapytaniu.

Zwalnianie systemu handlowego pracującego na SQL Server

Zgłoszenia o wolnej pracy Subiekta, WAPRO czy Comarcha rzadko wynikają z jednej przyczyny. Zaczynamy od rozstrzygnięcia, czy wąskim gardłem jest procesor, dysk, czy blokady między sesjami, bo każda z tych ścieżek prowadzi gdzie indziej, a wymiana serwera bez tej diagnozy bywa wydatkiem bez efektu. Zajmujemy się zarówno konfiguracją samej instancji, jak i sprzętem, na którym pracuje.