Hängen alle Worker-Threads an langsamen Aufgaben fest, warten neue Anfragen auf unbestimmte Zeit.
Warum Worker-Threads hängen fest, weil sie auf Antworten externer APIs oder der DB warten → Folge Für neue Anfragen ist kein Thread frei → Auf dem Bildschirm Endlos-Laden bei bestimmten Funktionen wie Login oder Shop
Timeouts für langsame Aufrufe, getrennte Thread-Pools pro Funktion, auf asynchrone Verarbeitung umstellen.
Im Graphen
Plateau am Limit · Threads und Warteschlangenlänge des Thread-Pools, Verarbeitungszeit der Anfragen
Wo nachsehen
Bei .NET Thread-Zahl und Warteschlangenlänge des Thread-Pools in dotnet-counters monitor prüfen (ab .NET 9 dotnet.thread_pool.thread.count und dotnet.thread_pool.queue.length, bis 8 ThreadPool Thread Count und ThreadPool Queue Length), mit dotnet-stack ermitteln, wo die Worker-Threads warten. Bei JVM und nativen Servern dasselbe per Thread-Dump prüfen
Spricht dafür
CPU-Auslastung deutlich unter 100 %, die Thread-Zahl steigt aber langsam und stetig oder klebt am Limit, die Warteschlange wächst, und die meisten Worker warten auf die Antwort desselben externen Aufrufs (DB, HTTP)
Spricht dagegen
Warteschlange leer, trotzdem langsam: Das aufgerufene System selbst ist langsam, also eher kaskadierender Ausfall oder Abhängigkeit von externen Diensten
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Teilen sich Paketempfang und Spiellogik denselben Worker-Thread-Pool, kommt die Paketverarbeitung des ganzen Servers zum Stillstand, sobald einige langsame Aufgaben alle Worker belegen.
Debug ThreadPool StarvationMicrosoft Sind keine Threads im Pool mehr frei und müssen neue Aufgaben warten, werden Antworten langsam, Ursache ist blockierender Code, der Threads belegt. Liegt die CPU in dotnet-counters deutlich unter 100 % und steigt dotnet.thread_pool.thread.count langsam und stetig, ist das ein Zeichen für einen erschöpften Pool (oft ist auch dotnet.thread_pool.queue.length hoch), mit dotnet-stack ermitteln, wo die Threads warten
Avoiding insurmountable queue backlogsAWS Gleichzeitig bearbeitete Anfragen = Ankunftsrate × Latenz (Littles Gesetz). Steigt bei 100 Anfragen pro Sekunde die Latenz von 100 ms auf 10 s, wachsen 10 Threads auf 1.000, und der Pool ist erschöpft
Bulkhead PatternMicrosoft Azure Mit eigenen Connection- und Thread-Pools pro aufgerufenem Dienst blockiert die Störung eines Dienstes nur dessen Pool
.NET runtime metrics.NET dotnet.thread_pool.thread.count (Threads im Thread-Pool) und dotnet.thread_pool.queue.length (wartende Aufgaben) gibt es ab .NET 9
Well-known EventCounters in .NETMicrosoft ThreadPool Thread Count (threadpool-thread-count) und ThreadPool Queue Length (threadpool-queue-length) bis .NET 8