SYS.DM_OS_TASKS

sys.dm_os_tasks zwraca listę zadań wykonywanych przez wątki silnika bazodanowego.

Zadanie, wątek i harmonogram jako trzy różne byty

Zrozumienie tego widoku wymaga rozdzielenia trzech pojęć, które w potocznym języku zlewają się w jedno. Harmonogram, opisany w sys.dm_os_schedulers, odpowiada jednemu rdzeniowi procesora widocznemu dla silnika i zarządza kolejką. Wątek roboczy z sys.dm_os_workers to fizyczny wykonawca przypisany do harmonogramu. Zadanie z omawianego widoku to porcja pracy, która wątkowi zostaje powierzona. Powiązanie idzie po kolumnach worker_address i scheduler_id, dzięki czemu da się prześledzić drogę od sesji użytkownika aż do konkretnego rdzenia. Bez tego łańcucha nie sposób odróżnić sytuacji, w której zapytanie czeka na procesor, od tej, w której czeka na zwolnienie blokady.

Połączenie z widokiem oczekiwań

Sam stan zadania mówi, że coś czeka, ale nie mówi na co. Odpowiedź daje dopiero złączenie z sys.dm_os_waiting_tasks po adresie zadania: pojawiają się tam typ oczekiwania, czas oczekiwania w milisekundach oraz — przy blokadach — identyfikator sesji blokującej. Typy zaczynające się od LCK_M_ oznaczają czekanie na blokadę innego użytkownika, PAGEIOLATCH_ czekanie na odczyt strony z dysku, CXPACKET i CXCONSUMER synchronizację między wątkami zapytania równoległego, ASYNC_NETWORK_IO sytuację, w której to aplikacja kliencka nie nadąża odbierać wyników. Ostatni przypadek jest szczególnie pouczający, bo wygląda jak problem serwera, a jest problemem stacji roboczej albo sieci.

Pułapki interpretacyjne przy zapytaniach równoległych

Wiersz o wartości exec_context_id równej zeru to wątek nadrzędny zapytania, pozostałe to wątki podrzędne. Liczenie zadań bez tego rozróżnienia sztucznie mnoży obraz aktywności — jedno zapytanie na ośmiu rdzeniach daje dziewięć wierszy. Kolejna sprawa to ustawienie maksymalnego stopnia równoległości i progu kosztu, przy którym silnik w ogóle rozważa zrównoleglenie; domyślny próg pochodzi z czasów, gdy sprzęt był nieporównanie wolniejszy, i na dzisiejszych serwerach powoduje zrównoleglanie zapytań, którym to szkodzi. Widać to właśnie jako wiele zadań w stanie oczekiwania na synchronizację przy niskim realnym postępie pracy. Warto też pamiętać, że wynik trzeba czytać razem z liczbą skonfigurowanych wątków roboczych, bo dopiero zestawienie obu wartości mówi, czy serwerowi kończy się zapas.

Kiedy warto zajrzeć serwerowi pod maskę

Typowy pretekst do takiej analizy to firma, w której program magazynowy działa sprawnie rano, a po południu przy pełnej obsadzie zaczyna gubić sekundy przy każdym zapisie dokumentu. Warszawskie Pogotowie Komputerowe rozstrzyga wtedy, czy wąskim gardłem jest serwer, sieć, czy pojedyncza stacja z zapełnionym dyskiem. Zajmujemy się jednym i drugim końcem tej układanki: obsługujemy zarówno serwery firmowe z oprogramowaniem handlowym opartym o SQL Server, jak i komputery pracowników, które w razie potrzeby odbieramy własnym transportem i zwracamy po naprawie.