RESOURCE_GOVERNOR_IDLE is recorded when a query is forced to sit idle because of a Resource Governor CPU cap (CAP_CPU_PERCENT). A cap is a hard ceiling: where the softer MAX_CPU_PERCENT only bites under contention, CAP_CPU_PERCENT inserts idle time into the runnable queue so the pool cannot exceed its percentage even on an otherwise idle server. This wait is that inserted idle time, made visible.
It matters doubly in the cloud: Azure SQL Database service tiers implement their CPU limits the same way, so this wait is a fixture on capped tiers.
Is It a Problem?
It is a policy, honestly reported. On-premises, its size shows exactly how much CPU your capped workload wanted but was denied; whether that is a problem depends on whether the cap still reflects intent. In Azure, sustained high values mean the workload wants more CPU than the tier provides, which is the cleanest scale-up signal the platform gives you.
Either way, no mystery: something asked for CPU and the governor said no.
Common Causes
CAP_CPU_PERCENTconfigured on a Resource Governor pool doing real work.- Azure SQL Database or Managed Instance workloads riding their tier’s CPU ceiling.
- A cap set long ago for a workload that has since grown.
What To Do
- Attribute it:
sys.dm_exec_requestsjoined to workload groups shows which pool’s queries are being idled. - On-premises, revisit the cap against current intent; raise or restructure pools if the throttled workload now matters more.
- In Azure, read it with
sys.dm_db_resource_stats(avg_cpu_percent pinned at the ceiling); either tune the biggest CPU consumers or scale the tier. - Do not chase it as a performance bug; it is configuration doing what it says.
How To See It
Rank it against everything else with Get-WaitStatistics; its share of wait time approximates how hard the cap is biting.
Part of the SQL Server Wait Types Library.
Related deep dive: SOS_SCHEDULER_YIELD Wait Type.
Leave a Reply