High Query Concurrency

Category: CPU · Also known as: High Number of Concurrently Running Processes

A lot of sessions are runnable or running at once - more work is ready than the CPUs can run, so sessions queue for a scheduler (not for data).

What this finding means

An unusually large number of sessions were running or runnable at the same moment. Runnable is the important word: those sessions have everything they need and are queued for a CPU scheduler. This is a queue for processor time, not a queue for data, which is what separates it from every wait-based finding.

Why it matters

A runnable queue is the most direct signal that demand has passed what the CPUs can serve. Every session in it is burning wall-clock time without doing work, and because the queue is invisible in most dashboards, the usual conclusion is that queries got slower. On a per-core licensed estate this is also the finding that most often turns into a procurement conversation, so being sure it is genuine matters financially.

How WISdom detects it

Sessions with status running or runnable are counted from sys.dm_exec_requests and sys.dm_exec_sessions, corroborated against the Processes performance counter. The count is compared to the four-week maximum for this minute-of-day. This rule is always evaluated, so it reports a value every minute whether or not it is elevated.


Collected from	Count of sessions with status running/runnable from sys.dm_exec_requests / sys.dm_exec_sessions; corroborated by the Processes performance counter.
Compared with	Max value during 15 minutes before and 15 minutes after of the same minute in the past 4 weeks
Related screen	Workload Activity

How it is scored

This rule is always evaluated, so it reports a value every minute whether or not it is elevated. It contributes an incident score of 2 when the value exceeds the four-week maximum for this minute-of-day.

How to read the numbers

Current against History max is the whole finding; the delta tells you how far outside normal this is. The Database CPU score is carried as context so you can see whether the composite agrees. A single spike is noise. The same elevated count across many consecutive minutes is the pattern that justifies acting.

What normally causes it

A small number of expensive statements occupying schedulers for long periods.
Trivial queries going parallel because the cost threshold for parallelism is left at its default.
A compile storm consuming CPU on plan generation rather than execution.
Genuine growth in concurrent users or batch work.

What this finding is not

Not the same as high CPU utilisation. Utilisation can be moderate while the runnable queue is long if work arrives in bursts.
Not a capacity verdict on its own. Tune the top statements and review parallelism first, because both routinely remove the queue without new hardware.
Not a storage or lock problem. Sessions waiting on data are suspended, not runnable, and show up under Resource Bottleneck instead.

What are some possible resolutions?

The options below are ranked. Option 1 fixes the cause where it lives and costs nothing; option 3 spends money or escalates, so try it last.

1. Tune the top CPU statements

A handful of statements usually account for most of the CPU. Fix those and concurrency falls without touching the server.

2. Stop trivial queries going parallel

If small statements are running in parallel, raise the cost threshold for parallelism and review MAXDOP. This frees schedulers with no new hardware.

3. Add CPU capacity

Only once the top statements and the parallelism settings are ruled out. Size it off the sustained peak, never off one interval.