Resource Bottleneck

Category: Waits · Also known as: Top Wait Category

One kind of wait is holding up most of the waiting sessions this minute. The wait type names the bottleneck - disk, locks, CPU, memory or log.

What this finding means

One wait category accounted for most of the waiting across active sessions this minute. Waits are how SQL Server accounts for time it spent not running, so the leading category is the fastest available pointer to which subsystem is the constraint: disk, locks, CPU scheduling, memory, network, or the log.

Why it matters

This finding exists to stop you tuning the wrong thing. Almost every wasted afternoon in database performance work starts with someone optimising a subsystem that was never the bottleneck. Reading the dominant wait first costs seconds and routinely redirects the whole investigation.

How WISdom detects it

Wait statistics from sys.dm_os_wait_stats are deltaed against the previous minute, benign and idle wait types are filtered out, and the remainder are mapped to a category. Sessions currently on that wait type are counted from sys.dm_exec_requests. The category total is compared to the four-week maximum for this minute-of-day.


Collected from	Wait deltas from sys.dm_os_wait_stats (this minute vs prior) mapped to category; sessions currently on that wait_type from sys.dm_exec_requests.
Compared with	Max value for category during 15 minutes before and 15 minutes after of the same minute in the past 4 weeks
Related screen	None

How it is scored

This rule fires only when the condition is met. It contributes an incident score of None when the finding is present, and 2 when it exceeds its four-week maximum.

How to read the numbers

Wait category names the subsystem. Sessions waiting distinguishes a single stuck session from a server-wide constraint, and it is the more important of the two: one session on a long wait is a query problem, most sessions on the same wait is a resource problem. Total wait is the aggregate time lost in the minute.

What normally causes it

Buffer IO waits: reads are going to disk, either because the access path is poor or because the buffer pool is too small for the working set.
Lock waits: contention, which routes to the Blocking or Deadlock findings.
CPU scheduling waits: more runnable work than schedulers, which routes to High Query Concurrency.
Log write waits: commit throughput limited by the log volume.

What this finding is not

Not a fix in itself. The wait names the resource. Open the finding for that resource to get the action.
Not meaningful in isolation for benign waits. Idle and background waits are filtered out deliberately, because including them makes the top wait meaningless.
Not a ranking of importance. The largest wait category is the largest, not necessarily the one hurting users most. A small lock wait can matter more than a large IO wait.

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. Open the finding for that wait class

The wait names the resource, not the fix. Buffer IO points at storage, LCK at blocking, SOS_SCHEDULER at CPU. Open that finding for the real action.

2. Confirm who is waiting

Check the sessions on this wait in the Activity tab. One session waiting is a query problem; most sessions waiting is a resource problem.

3. Escalate to the resource owner

If the wait maps to something you do not own, array latency or host CPU on a shared cluster, hand over the wait class, the session count, and the duration. Those three numbers are the whole case.