Dlaczego THREADPOOL czeka, mimo że mam dostępne wątki?
Widzimy przekroczenia limitów czasu aplikacji i dzięki zestawowi pierwszej pomocy udało mi się uchwycić szczegóły. Jedną z rzeczy, które zwróciły moją uwagę, było:
Wykryto oczekiwanie na truciznę: pula wątków
Więc uruchomiłem poniższe zapytania:
---get thread pool waits---thread pool wait query
SELECT count(*) FROM sys.dm_os_waiting_tasks
where wait_type ='threadpool'
-- get threads available--Threads available query
declare @max int
select @max = max_workers_count from sys.dm_os_sys_info
select
@max as 'TotalThreads',
sum(active_Workers_count) as 'CurrentThreads',
@max - sum(active_Workers_count) as 'AvailableThreads',
sum(runnable_tasks_count) as 'WorkersWaitingForCpu',
sum(work_queue_count) as 'RequestWaitingForThreads' ,
sum(current_workers_count) as 'AssociatedWorkers',
Getdate() as 'DateLogged'
from
sys.dm_os_Schedulers where status='VISIBLE ONLINE'
Kiedy uruchamiam zapytanie „oczekiwanie na pulę wątków”, oczekiwania puli wątków pojawiają się w powyższym wyniku (czasami ponad 20 wyników) przez ułamek sekundy, a następnie znikają po ponownym uruchomieniu. Ale mogłem zobaczyć ponad 400 wątków dostępnych w drugim zestawie wyników za pośrednictwem zapytania „dostępne wątki”.
Nie jestem w stanie zrozumieć, dlaczego widzę THREADPOOL
oczekiwania, kiedy uruchamiam pierwsze zapytanie, ale drugie zapytanie pokazuje, że wątki są nadal dostępne. Czy ktoś może wyjaśnić?
- Maxdop: 8
- Maksymalny stopień równoległości: 50
Pula wątków czeka:


Odpowiedzi
Nie jestem w stanie zrozumieć, dlaczego widzę, że THREADPOOL czeka, gdy uruchamiam pierwsze zapytanie, ale drugie zapytanie pokazuje, że wątki są nadal dostępne. Czy ktoś może wyjaśnić?
Zauważyłem, że można zobaczyć wiele naprawdę krótkich THREADPOOL
czasów oczekiwania (po kilka milisekund), podczas gdy SQL Server pobiera wątki z systemu operacyjnego.
Może się tak zdarzyć, jeśli na przykład SQL Server był przez jakiś czas bezczynny, a następnie kilka równoległych zapytań jest wykonywanych jednocześnie. Te zapytania będą musiały czekać, aż system operacyjny dostarczy wątki do procesu sqlservr.exe, gromadząc THREADPOOL
w tym czasie oczekiwania.
Możesz potwierdzić, że tak się dzieje, obserwując licznik PerfMon „Proces” -> „Liczba wątków”. Generalnie, ilekroć ta wartość gwałtownie rośnie, możesz zobaczyć te THREADPOOL
oczekiwania.
Na moim blogu ( Unusual THREADPOOL Waits ) znajduje się pełne demo tego zachowania , oto podsumowanie:
Wracając do tego linku do dokumentów:
Występuje, gdy zadanie oczekuje na uruchomienie procesu roboczego.
W typowym przypadku dzieje się tak, ponieważ osiągnęliśmy logiczny limit ustawiony przez SQL Server dla liczby wątków roboczych, które można mieć jednocześnie.
W nietypowym przypadku zadanie czeka na pracownika, ponieważ SQL Server przydziela wątek (żądając go od systemu operacyjnego), który jest potrzebny do obsługi tego pracownika.
Żeby było jasne, byłbym zaskoczony, gdyby te oczekiwania były przyczyną przekroczenia limitu czasu aplikacji.