Dlaczego THREADPOOL czeka, mimo że mam dostępne wątki?

Aug 16 2020

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ę THREADPOOLoczekiwania, 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

4 JoshDarnell Aug 27 2020 at 21:38

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 THREADPOOLczasó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 THREADPOOLw 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 THREADPOOLoczekiwania.

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.