An ASP.NET Core API has rising latency and timeouts but CPU is not saturated. How would you prove or disprove ThreadPool starvation?

Prove ThreadPool starvation with counters, stacks, and traces

Combines ThreadPool counters, repeated stack snapshots, and wait-event traces to distinguish blocked workers from CPU or dependency pressure.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I correlate request latency with ThreadPool thread count, queue length, completed work rate, CPU, and dependency latency. Starvation is likely when work queues grow, completion falls behind, and the pool keeps adding threads while CPU still has room. I then capture repeated managed stack snapshots during the bad interval. If many workers repeatedly sit in .Result, .Wait, synchronous I/O, lock acquisition, or another blocking path, the stacks explain why threads are unavailable. For intermittent blocking, I collect a bounded trace with ThreadPool and wait events so I can see when workers block, how long they wait, and which call path caused it. That separates starvation from an overloaded downstream service, pure CPU saturation, or normal temporary thread injection.

Full answer below

Practice focus

ThreadPool queueing, thread injection, completed work, sync-over-async, blocking stacks, wait events, dependency latency, and bounded concurrency.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
ThreadPool starvation is often blamed whenever an API is slow. The diagnosis needs both a queueing pattern and evidence of what keeps workers unavailable.
I correlate request latency with ThreadPool thread count, queue length, completed work rate, CPU, and dependency latency. Starvation is likely when work queues grow, completion falls behind, and the pool keeps adding threads while CPU still has room. I then capture repeated managed stack snapshots during the bad interval. If many workers repeatedly sit in .Result, .Wait, synchronous I/O, lock acquisition, or another blocking path, the stacks explain why threads are unavailable. For intermittent blocking, I collect a bounded trace with ThreadPool and wait events so I can see when workers block, how long they wait, and which call path caused it. That separates starvation from an overloaded downstream service, pure CPU saturation, or normal temporary thread injection.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I look for a dominant repeated pattern rather than one blocked thread. A slow database or HTTP dependency can create starvation when code waits synchronously, but the dependency latency is still part of the cause. Lock contention may show many workers waiting behind one owner, while unbounded parallel work may flood the queue even with async code. I compare healthy and unhealthy endpoints and include request volume because the same blocking path can appear harmless at low concurrency. The fix follows the evidence: async I/O end to end, shorter lock scope, bounded concurrency, backpressure, a worker boundary for CPU-heavy work, or a dependency timeout and bulkhead.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I avoid treating minimum worker-thread tuning as the primary repair. Raising the minimum can shorten the pool's ramp-up in a narrow workload, but it can also increase memory, context switching, and pressure on a database or remote service while preserving the blocking defect. Runtime versions have different starvation heuristics and wait-event support, so I record the exact runtime and use evidence available there. I verify the diagnostic attachment did not target a parent dotnet process or the wrong replica. After the code or concurrency change, I repeat the same load shape and compare queue duration, thread count, completed work, dependency concurrency, tail latency, and timeouts through startup and traffic bursts. The durable guard may be a load test with a queue-length budget and a trace captured on regression, not a unit test that only proves the method returns asynchronously.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Calling low CPU and high latency proof of starvation without queue or stack evidence.
Finding one blocked thread and assuming it represents the process.
Converting method signatures to async while a synchronous dependency still blocks underneath.
Increasing minimum threads before identifying the blocking or concurrency boundary.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Thread count rises continuously while the dependency receives unbounded concurrent work.
Stack snapshots are taken after traffic stops and no longer contain the blocking pattern.
The investigation ignores lock owners, downstream latency, or CPU-heavy background jobs.
The proposed fix has no burst-load or tail-latency verification.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Why can starvation happen without high CPU?
When are repeated stack snapshots better than one dump?
Why might raising minimum threads make another service fail?

Continue the section