Warum wartet THREADPOOL, obwohl Threads verfügbar sind?

Aug 16 2020

Wir sehen Anwendungsüberschreitungen und mit Hilfe des First Responder Kits habe ich Details erfasst. Eines der Dinge, die meine Aufmerksamkeit erregt haben, war:

Giftwarte erkannt: Thread Pool

Also lief ich unten Fragen:

---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'

Wenn ich die Abfrage "Thread-Pool-Wartezeit" ausführe, werden Thread-Pool-Wartezeiten im obigen Ergebnis (manchmal mehr als 20 Ergebnisse) für den Bruchteil einer Sekunde angezeigt und verschwinden dann, wenn ich sie erneut ausführe. In der zweiten Ergebnismenge konnten jedoch mehr als 400 Threads in der Abfrage "Threads verfügbar" angezeigt werden.

Ich kann nicht verstehen, warum THREADPOOLbeim Ausführen der ersten Abfrage Wartezeiten auftreten, aber die zweite Abfrage zeigt, dass noch Threads verfügbar sind. Kann jemand bitte erklären?

  • Maxdop: 8
  • Maximaler Parallelitätsgrad: 50

Thread-Pool wartet:

Antworten

4 JoshDarnell Aug 27 2020 at 21:38

Ich kann nicht verstehen, warum THREADPOOL beim Ausführen der ersten Abfrage wartet, aber die zweite Abfrage zeigt, dass noch Threads verfügbar sind. Kann jemand bitte erklären?

Ich habe festgestellt, dass Sie viele wirklich kurze THREADPOOLWartezeiten (jeweils eine Handvoll Millisekunden) sehen können, während SQL Server Threads vom Betriebssystem abruft.

Dies kann beispielsweise der Fall sein, wenn SQL Server eine Weile inaktiv war und dann mehrere parallele Abfragen gleichzeitig ausgeführt werden. Diese Abfragen müssen warten, während das Betriebssystem Threads für den Prozess sqlservr.exe bereitstellt und THREADPOOLwährend dieser Zeit Wartezeiten ansammelt .

Sie können dies bestätigen, indem Sie den PerfMon-Zähler "Process" -> "Thread Count" beobachten. Wenn dieser Wert schnell ansteigt, werden diese THREADPOOLWartezeiten im Allgemeinen angezeigt.

In meinem Blog ( Ungewöhnliche THREADPOOL Waits ) finden Sie eine vollständige Demo dieses Verhaltens. Hier die Zusammenfassung:

Zurück zu diesem Dokument-Link:

Tritt auf, wenn eine Aufgabe darauf wartet, dass ein Mitarbeiter ausgeführt wird.

Im typischen Fall liegt dies daran, dass wir die logische Grenze erreicht haben, die SQL Server für die Anzahl der Worker-Threads festgelegt hat, die Sie gleichzeitig haben können.

In ungewöhnlichen Fällen wartet die Aufgabe auf einen Worker, da SQL Server den Thread zuweist (der ihn vom Betriebssystem anfordert), der zur Sicherung dieses Workers erforderlich ist.

Um es klar auszudrücken, wäre ich überrascht, wenn diese Wartezeiten die Ursache für Ihre Bewerbungszeitüberschreitungen wären.