Why this problem matters
Sustained high CPU can indicate expensive queries, excessive compilation, or concurrent workload pressure. An operating-system percentage alone does not identify which work inside SQL Server creates the pressure.
How to diagnose it
Sample runnable_tasks_count and active_workers_count for online schedulers over time. Correlate CPU-consuming queries, parallelism behavior, and compilation activity within the same interval.
The query reads the current state of online visible schedulers. Runnable task count in a single sample is not diagnostic by itself; duration and query evidence are required.
SELECT parent_node_id,
scheduler_id,
current_tasks_count,
runnable_tasks_count,
current_workers_count,
active_workers_count,
work_queue_count,
load_factor
FROM sys.dm_os_schedulers
WHERE status = 'VISIBLE ONLINE'
ORDER BY runnable_tasks_count DESC, scheduler_id;A safe solution approach
Start with validated queries that consume the most total or per-execution CPU. Consider hardware or parallelism changes only after measuring query plans and capacity requirements.
Why continuous monitoring matters
CPU pressure may be limited to workload peaks and remain hidden in averages. moon can track trends with low overhead and route sustained-pressure alerts through Slack, PagerDuty, or webhooks.
Frequently asked questions
Is 100 percent CPU always a SQL Server problem? Does high runnable_tasks_count alone justify adding processors?
No, other server processes can consume CPU and brief peaks may be acceptable. The queue must be persistent and interpreted with evidence from expensive queries and capacity demand.
How does moon help with this problem?
moon continuously observes SQL Server, PostgreSQL, and MongoDB signals, helping teams evaluate the problem as a trend instead of relying on a one-time check.