Widok sys.dm_os_threads

sys.dm_os_threads pokazuje informacje o wątkach systemowych wykorzystywanych przez instancję.

Widok sys.dm_os_threads — czym jest i do czego służy

Widok sys.dm_os_threads należy do dynamicznych widoków zarządzania dostępnych w SQL Server. Udostępnia informacje o wątkach tworzonych i utrzymywanych przez system wykonawczy instancji. Wątek można traktować jako jednostkę pracy planowaną przez system operacyjny. To właśnie wątki realizują fragmenty zadań związanych między innymi z obsługą żądań, wykonywaniem planów zapytań, operacjami wejścia i wyjścia, synchronizacją oraz działaniami tła.

Sam widok nie jest dziennikiem historii. Zawartość opisuje stan obserwowany w momencie wykonania zapytania, dlatego dwa odczyty wykonane w różnych chwilach mogą zwrócić inny zestaw wierszy albo odmienne wartości. Wątek może zakończyć pracę, zostać ponownie użyty lub zmienić powiązanie z zadaniem. Z tego powodu wynik powinien być interpretowany jako bieżący obraz środowiska wykonawczego, a nie jako kompletna lista wszystkich wątków, które kiedykolwiek istniały.

W praktyce sys.dm_os_threads jest wykorzystywany podczas diagnozowania nietypowego obciążenia procesora, dużej liczby aktywnych zadań, problemów z planowaniem oraz sytuacji, w których standardowe widoki sesji nie wyjaśniają zachowania instancji. Szczególne znaczenie ma zestawienie danych o wątkach z informacjami o zadaniach, schedulerach, żądaniach i sesjach. Dopiero taka korelacja pozwala ustalić, czy obserwowany wątek wykonuje konkretną pracę, oczekuje na zasób, czy należy do mechanizmu działającego w tle.

sys.dm_os_threads w kontekście zadań, schedulerów i procesora

W analizie należy odróżnić wątek od zadania. Wątek jest zasobem wykonawczym widzianym z perspektywy systemu operacyjnego, natomiast zadanie opisuje jednostkę pracy rozpoznawaną przez mechanizmy SQL Server. Jedno zadanie może w określonych okolicznościach korzystać z wątku, a powiązania pomiędzy tymi obiektami mogą zmieniać się w czasie. Nie powinno się więc zakładać, że liczba wierszy w sys.dm_os_threads jest równa liczbie sesji, zapytań albo aktywnych użytkowników.

Przydatne porównanie stanowi zestawienie sys.dm_os_threads z widokiem sys.dm_os_workers. Wątek opisuje wykonanie na poziomie systemu operacyjnego, a worker reprezentuje wewnętrzny kontekst używany do realizacji pracy przez silnik. Dodatkowych informacji dostarcza sys.dm_os_tasks, gdzie można szukać aktualnych zadań oraz ich powiązań z workerami. Z kolei sys.dm_exec_requests i sys.dm_exec_sessions pomagają przejść od niskopoziomowego obrazu wykonania do konkretnego żądania lub połączenia.

Warto także uwzględnić schedulery. Scheduler określa logiczny kontekst planowania pracy, zwykle powiązany z dostępnym procesorem logicznym. Informacja o schedulerze może pomóc ocenić, czy obciążenie skupia się w jednym miejscu, czy jest rozłożone szerzej. Nierównomierny rozkład nie musi oznaczać błędu, ponieważ wpływ mogą mieć powinowactwo procesora, charakter obciążenia, priorytety oraz chwilowy przebieg zadań. Pojedynczy wynik bez porównania w czasie nie wystarcza do formułowania kategorycznych wniosków.

W odróżnieniu od widoków pokazujących zapytania, sys.dm_os_threads może ujawnić warstwę, która pozostaje niewidoczna na poziomie samego tekstu SQL. Dzięki temu można sprawdzić, czy problem dotyczy rzeczywistego wykonywania, oczekiwania, przełączania kontekstu, synchronizacji albo prac pomocniczych. Analiza powinna obejmować także system operacyjny, ponieważ część obserwowanych zachowań wynika z konkurencji o procesor lub pamięć poza samą bazą danych.

Typowe problemy widoczne przez sys.dm_os_threads

Jednym z częstszych sygnałów jest większa niż oczekiwana liczba wątków. Nie zawsze oznacza ona awarię. Wątki mogą być tworzone dla różnych rodzajów pracy, a ich obecność może pozostawać związana z konfiguracją, liczbą aktywnych zadań, mechanizmami równoległości oraz operacjami pomocniczymi. Niepokój powinien wzbudzić przede wszystkim trwały trend połączony z wysokim użyciem procesora, opóźnieniami, długimi kolejkami lub narastającą liczbą oczekujących zadań.

Innym przypadkiem jest trudność w przypisaniu wątku do konkretnej aktywności. Wynika ona z tego, że identyfikatory i relacje są obserwowane w czasie rzeczywistym. Między odczytem jednego widoku a odczytem drugiego może nastąpić zmiana stanu. Wątek może zakończyć pracę, a zadanie może zostać przekazane do innego kontekstu. Dlatego podczas korelacji warto wykonywać odczyty możliwie blisko siebie i zapisywać czas obserwacji.

Problemy z planowaniem mogą objawiać się długim oczekiwaniem na wykonanie, choć samo zapytanie nie musi być wadliwe. Przyczyną może być przeciążenie procesora, nadmierna równoległość, blokowanie, oczekiwanie na operacje dyskowe albo konflikt o zasoby pamięci. sys.dm_os_threads pomaga określić skalę zjawiska, ale nie powinien być jedynym źródłem diagnozy. Wymagane jest sprawdzenie liczników systemowych, planów wykonania, typów oczekiwań oraz aktywności w czasie.

Niepoprawne wnioski mogą powstać również wtedy, gdy pojedynczy identyfikator zostanie potraktowany jako trwała etykieta konkretnego procesu. Identyfikatory są przydatne do korelacji w obrębie określonego odczytu, lecz nie należy bez sprawdzenia porównywać ich z dawnymi wynikami. W raportach diagnostycznych powinno się zapisywać datę, godzinę, nazwę instancji, zakres zapytania oraz dodatkowe widoki użyte do interpretacji.

Praktyczne wskazówki dla analizy Widok sys.dm_os_threads

Najpierw powinno się wykonać prosty odczyt metadanych i sprawdzić, jakie kolumny są dostępne w konkretnej wersji SQL Server. Zakres oraz znaczenie poszczególnych pól może zależeć od wydania, uprawnień i środowiska. Zapytanie diagnostyczne powinno jawnie wskazywać potrzebne kolumny zamiast używać SELECT *. Ułatwia to porównywanie wyników, ogranicza ilość danych i zmniejsza ryzyko problemów po zmianie schematu widoku.

Przy krótkim badaniu można rozpocząć od uporządkowania wyników według identyfikatorów związanych z wątkiem, workerem lub schedulerem, jeżeli są dostępne. Następnie należy zestawić je z listą zadań i żądań. Warto wykonywać kilka próbek w odstępach czasowych, ponieważ pojedynczy odczyt może uchwycić chwilowy skok. Dopiero powtarzalność zjawiska wskazuje, że obserwowany stan ma znaczenie operacyjne.

Podczas pracy diagnostycznej przydatne jest rozdzielenie obserwacji na trzy poziomy:

• poziom systemu operacyjnego, obejmujący użycie procesora, pamięci, kolejki oraz procesy;
• poziom silnika SQL Server, obejmujący wątki, workery, schedulery, zadania i typy oczekiwań;
• poziom aplikacji, obejmujący sesje, żądania, tekst zapytań, plany wykonania i wzorzec ruchu.

Takie rozdzielenie pomaga uniknąć przypisywania całej odpowiedzialności jednej warstwie. Jeżeli wysoka liczba wątków występuje tylko podczas krótkiego, oczekiwanego zadania, może nie wymagać korekty. Jeżeli natomiast towarzyszy jej stałe przeciążenie i rosnące opóźnienia, należy zbadać źródło pracy, ustawienia równoległości, blokady, operacje wejścia i wyjścia oraz ograniczenia sprzętowe. Zmiany konfiguracyjne powinny być poprzedzone pomiarem i wykonane w sposób umożliwiający wycofanie.

Nie powinno się usuwać wątków ani wymuszać zakończenia zadań wyłącznie na podstawie ich obecności w widoku. Taka ingerencja może przerwać prawidłową pracę albo utrudnić zebranie dowodów. Bezpieczniejszym podejściem jest zebranie próbek, porównanie ich z obciążeniem aplikacji oraz sprawdzenie, czy występuje korelacja z konkretnymi zapytaniami lub okresami zwiększonego ruchu.

Kiedy zgłosić się do serwisu z problemem sys.dm_os_threads

Do konsultacji warto przygotować się wtedy, gdy odczyty sys.dm_os_threads wskazują powtarzalne przeciążenie, a jednocześnie pojawiają się opóźnienia aplikacji, niestabilna praca, nagłe spadki wydajności albo trudność z ustaleniem źródła obciążenia. Przydatne będą daty i godziny próbek, treść użytych zapytań diagnostycznych, informacje o wersji SQL Server oraz opis tego, co dokładnie dzieje się po stronie użytkownika. Takie materiały skracają etap rozpoznania i ułatwiają oddzielenie problemu z konfiguracją od problemu sprzętowego.

W sprawach wymagających oceny komputera lub środowiska pracy można skontaktować się z firmą Warszawskie Pogotowie Komputerowe 24/7. Przed przekazaniem danych zaleca się usunięcie haseł, tokenów, pełnych danych osobowych oraz fragmentów zapytań zawierających poufne informacje. Sama obserwacja widoku nie daje jeszcze podstaw do jednoznacznej diagnozy, dlatego sensowne jest przekazanie również objawów, czasu występowania oraz zmian wykonanych przed pojawieniem się problemu.

Jeżeli zjawisko występuje tylko raz i nie powoduje widocznych skutków, wystarczające może być dalsze monitorowanie. Jeżeli jednak powtarza się w określonych godzinach, narasta albo wpływa na dostępność aplikacji, należy rozpocząć uporządkowaną diagnostykę. Właściwa interpretacja sys.dm_os_threads polega na połączeniu danych o wątkach z kontekstem zadań, schedulerów, żądań i zasobów systemowych, a nie na ocenianiu pojedynczej wartości w izolacji.