[FEATURE] CPU alerts: surface total non-idle CPU, not just SQL Server scheduler %

[BrucesOfValant]

Component

Lite

Performance Monitor Version

2.8.0

SQL Server Version

Microsoft SQL Server 2019 (RTM-CU32-GDR) (KB5077469) - 15.0.4460.4 (X64) Feb 13 2026 17:00:40 Copyright (C) 2019 Microsoft Corporation Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2019 Datacenter 10.0 (Build 17763: ) (Hypervisor)

Windows Version

Windows 11 (current patches applied)

Describe the Bug

I am using the lite version to monitor a production server. I also have DataDog metrics running for the same server. The CPU utilization numbers as higher in Lite than they are in DataDog. This becomes inaccurate and not worth alerting on.

Claude states:
`Why the discrepancy?
The smoking gun: In the sql-monitor-2 data, other_process_cpu is 0 for every single sample — meaning it reports sql_server_cpu + idle_cpu = exactly 100% at all times. That's almost certainly a collection artifact, not reality.

This inflates the apparent SQL Server CPU percentage. Here's why:

sql-monitor-2 reads from sys.dm_os_ring_buffers (RING_BUFFER_SCHEDULER_MONITOR). The OtherProcessUtilization value (non-SQL Server processes) appears to be either missing or zeroed out in how Performance Monitor Lite calculates it, making SQL Server's share look larger than it is.
DataDog reads from Windows OS-level counters — a more accurate picture of total machine CPU. User + system averaging ~19–22% total is the realistic baseline load.
The trend shape matches between both sources (peak around 11:00 PDT, tapering off through the afternoon), which confirms they're measuring the same activity — just with different denominators.

Bottom line: DataDog's ~20–30% total CPU is likely closer to reality. The Performance Monitor Lite numbers are overstated due to other_process_cpu being reported as 0, making SQL Server appear to own 100% of non-idle CPU when it doesn't.`

Steps to Reproduce

1. Open Lite edition
2. Configure to connect to server (elevated rights for testing only)
3. Watch CPU utilization metrics (front panel, or charts for server)
4. Compare to metrics gathered by Datadog.
5. Zoom in Datadog charts to a few minutes to eliminate Rollup averaging, set chart query to show MAX values.
6. Note that Lite metrics are significantly higher than DataDog OS (user + system) utilization metric.

Expected Behavior

CPU utilization metrics should match the same values as closely as possible to eliminate false positive alerts and user confusion.

Actual Behavior

Example: At this moment Lite reports utilization is at 64%. DataDog shows it bouncing around 33 to 41% utilization for the last 5 minutes. No MAX peaks above 41%

Error Messages / Log Output

No errors listed

Screenshots

Additional Context

No response

[erikdarlingdata]

Thanks for the report, but the diagnosis pasted from the LLM isn't right and the underlying premise needs unpacking before this can be called a bug.

What Lite actually collects. The ring-buffer query is Lite/Services/RemoteCollectorService.Cpu.cs. It reads three values from RING_BUFFER_SCHEDULER_MONITOR:

• sqlserver_cpu_utilization = ProcessUtilization — read directly from the XML, not derived.
• SystemIdle — read directly.
• other_process_cpu_utilization = 100 − SystemIdle − ProcessUtilization (clamped to 0).

That's the canonical pattern from Microsoft's own docs for this ring buffer. SQL Server's CPU number is not computed from other_process_cpu, so other_process_cpu = 0 cannot inflate it. The LLM got the causal direction wrong.

Why other_process_cpu shows 0. On a dedicated SQL Server, that's the expected reading — nothing else of consequence is on the box, so SystemIdle + ProcessUtilization ≈ 100. It's not a collection artifact.

Why the two tools disagree on the absolute number. They are not measuring the same thing.

• DataDog's "user + system" is an OS-level total across all processes, sampled by Windows performance counters.
• The ring buffer's ProcessUtilization is SQL Server's own accounting of how busy its schedulers were, computed from worker runtime vs. scheduler tick budget.

On virtualized hosts (your screenshot says "Hypervisor"), those two views legitimately diverge. SQL Server doesn't see hypervisor stolen time the same way Windows does, scheduler tick budgets can skew high under contention or oversubscription, and CU-level scheduler changes occasionally shift how ProcessUtilization reports. A 64% / 33–41% spread on a busy guest VM is not unusual and doesn't mean either source is "wrong."

What to check if you want to dig in.

1. Compare the ring buffer to the SQL-Server-process-only counter Process(sqlservr)\% Processor Time divided by logical CPU count. If those two agree (and they usually do), the ring buffer is reporting accurately and the gap is just SQL-process-CPU vs. whole-machine-CPU.
2. Check sys.dm_os_schedulers for runnable/preemptive activity at the moments where the gap is widest — that often explains scheduler-time-vs-OS-time divergence.
3. If you're on a noisy hypervisor, ask the platform team about CPU ready/stolen time during those windows.

Happy to dig further if any of the above turns up something concrete, but I don't see a bug in Lite based on what's posted.

[BrucesOfValant]

Feel free to close the ticket if you want.

All my problems are dealing with the system CPU going high, traced back to SQL Server user process. System CPU spikes, its is SQL's fault. Typically an out of control external server or a bad plan being used 10,000 times in parallel. (yes, we hunt them down and solve them).

The metric in lite (and presumably in full) has low value in that scenario. Okay, SQL Server thinks it is busy relatively. The server itself things are hunky dory. My pain is when the SQL process is what consumes 99% of CPU time as a user process. Having a metric that trips at 65% (or even 80 if I go silly) real CPU feels high value.

[erikdarlingdata]

That's a fair use case and I won't close it on that basis. You're after "is the box in trouble" rather than "how busy are SQL Server's schedulers" — those answer different questions and you want the first one for alerting.

Good news: the data is already there. The ring-buffer query stores sql_server_cpu_utilization and other_process_cpu_utilization separately. Their sum is 100 − SystemIdle, which is total non-idle CPU and tracks a lot closer to DataDog's "user + system." It's just not what the headline number and the alert threshold are wired to right now.

Want me to retitle this issue as a feature request to (a) display total CPU alongside the SQL-only number and (b) let the alert threshold target either, defaulting to total? That's a small, well-scoped change and matches what you're describing.

[BrucesOfValant]

That would be swell. Thank you.

[erikdarlingdata]

Retitled and relabeled as a feature request. Scope:

1. Surface total non-idle CPU (sql_server_cpu + other_process_cpu) alongside the existing SQL-only number, so users can see both at a glance.
2. Let the CPU alert threshold target either metric, defaulting to total non-idle CPU (the "is the box in trouble" view).
3. Apply to Lite first; mirror to Dashboard if/when it makes sense.

Will pick up in a future release. Thanks for pushing back when the first answer didn't fit your scenario — the use case is clear and it's a real gap.

[erikdarlingdata]

Shipped in PR #902 (merged to dev).