Host Storage Pressure
Category: Storage · Also known as: High Host Storage Metacounter score
WISdom’s composite storage pressure score for the host is high this minute - a single rolled-up health number built from the underlying counters.
What this finding means
Section titled “What this finding means”WISdom’s composite storage pressure score for the host, on a 0 to 100 scale, was high for the minute. This measures the volumes as the machine sees them, covering all IO on those volumes rather than only this instance’s.
Why it matters
Section titled “Why it matters”Storage is where the largest cheques get written on the weakest evidence. Distinguishing a volume that is genuinely slow from a volume that is being asked for more than it can serve is the difference between a capacity purchase and a scheduling change, and only the host view can tell them apart.
How WISdom detects it
Section titled “How WISdom detects it”WISdom rolls the host storage 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 Storage metacounter - a weighted composite of the perf counters and wait stats for storage 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
Section titled “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
Section titled “How to read the numbers”Score against History max, then identify which volume. Data, log, and tempdb behave differently and frequently sit on different storage, so an aggregate score hides the answer. Latency per operation and queue depth together tell you whether the volume is slow or simply oversubscribed; those two have different fixes.
What normally causes it
Section titled “What normally causes it”- Data, log, and tempdb sharing one volume, the most common self-inflicted storage problem.
- Backups or maintenance running against the same volume as the live workload.
- Another workload on shared storage, common on a SAN or in a virtualised estate.
- Genuine array latency or a degraded storage path.
What this finding is not
Section titled “What this finding is not”- Not the same as Database Storage Pressure. Host pressure with a quiet database means something else on the machine or the array is responsible.
- Not a capacity case without the numbers. Latency per operation, the volume name, and the throughput ceiling are what a storage team can act on. A score is not.
- Not uniform across volumes. Always break the score down before drawing a conclusion.
What are some possible resolutions?
Section titled “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. Identify the slow volume
Section titled “1. Identify the slow volume”Work out which volume is slow and by how much. Data, log, and tempdb behave differently and often sit on different storage.
2. Move competing work off that volume
Section titled “2. Move competing work off that volume”Backups, log, and tempdb sharing one volume is the most common self-inflicted storage problem. Separate them.
3. Escalate with the latency numbers
Section titled “3. Escalate with the latency numbers”Take stall time per read, the volume name, and the throughput ceiling to whoever owns the array. Those three numbers are the entire conversation.