Host CPU Pressure

Category: CPU · Also known as: High Host CPU Metacounter score

WISdom’s composite CPU pressure score for the host is high this minute - a single rolled-up health number built from the underlying counters.

What this finding means

WISdom’s composite CPU pressure score for the host, on a 0 to 100 scale, was high for the minute. This measures the machine, covering every process on it, not just this SQL Server instance.

Why it matters

The host view is what stops you tuning a database that was never the problem. When the host is under pressure and the instance is not, the cause is outside SQL Server entirely, and no amount of query work will help. On virtualised or consolidated estates this is a routine occurrence rather than an edge case.

How WISdom detects it

WISdom rolls the host CPU performance counters and wait statistics into one weighted score per minute, then compares it to the four-week maximum for this minute-of-day. The rule is always evaluated and returns a score every minute.


Collected from	WISdom Host CPU metacounter - a weighted composite of the perf counters and wait stats for CPU at the host level.
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	Performance Metrics

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

Score against History max, then compare directly against Database CPU Pressure for the same minute. That comparison is the finding’s real value: host high with database normal means look outside SQL Server, both high means the instance is the consumer, and host normal with database high means the host is coping with a heavy tenant.

What normally causes it

Another SQL Server instance on the same host consuming processor.
Non-database workload: antivirus scans, backup agents, monitoring agents, scheduled tasks.
Hypervisor-level contention, such as CPU ready time from an oversubscribed host.
This instance genuinely consuming the machine, which the database-level score confirms.

What this finding is not

Not attributable to SQL Server by default. Confirm the instance’s share before acting.
Not visible to the database counters. A database can look completely healthy while the host it runs on is saturated.
Not a right-sizing trigger on its own. Identify the consumer first; adding cores to a host starved by an antivirus scan solves nothing and costs licence.

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. Confirm SQL Server is the consumer

Host pressure is not always ours. Compare the instance’s CPU against the host total before tuning anything inside the database.

2. Find the other workload on the host

Antivirus, a backup agent, another instance, or a noisy neighbour VM. Host CPU high with a quiet instance means the answer is outside SQL Server.

3. Right-size the host

Only once the instance is cleared and the other consumers are known. The capacity planner sizes this from the sustained profile.