Database Memory Pressure
Category: Memory · Also known as: High Database Memory Metacounter score
WISdom’s composite memory pressure score for the database 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 memory pressure score for this database, on a 0 to 100 scale, was high for the minute. It rolls up the memory-related counters and waits attributable to this database, including buffer pool behaviour, memory grants, and cache churn.
Why it matters
Section titled “Why it matters”Memory pressure is where query problems and capacity problems are hardest to tell apart, and the two have opposite costs: one is a free tuning fix, the other is a purchase. The composite is the trigger for that investigation, not the answer to it.
How WISdom detects it
Section titled “How WISdom detects it”WISdom rolls the memory performance counters and wait statistics for the database 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 Database Memory metacounter - a weighted composite of the perf counters and wait stats for memory at the database 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. Underneath, three very different things read as memory pressure: buffer pool churn, which is usually a read-volume problem; memory grants pending, which is usually one oversized grant from a bad estimate; and plan cache growth, which is usually a compilation problem. Identify which before acting.
What normally causes it
Section titled “What normally causes it”- High read volume evicting pages from the buffer pool faster than they are reused.
- An oversized memory grant from a bad row estimate, holding memory other sessions need.
- Plan cache bloat from unparameterized SQL consuming memory that would otherwise cache data.
- A working set that has genuinely outgrown the configured memory.
What this finding is not
Section titled “What this finding is not”- Not a signal to add memory. More memory hides a read-volume problem at recurring cost; that is the ordering the resolutions below deliberately enforce.
- Not a host measurement. If Host Memory Pressure is normal, the constraint is how this database uses its allocation, not how much the host has.
- Not comparable between databases. The score is relative to each database’s own history.
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. Open the counters behind the score
Section titled “1. Open the counters behind the score”See what drove it. Buffer pool churn, memory grants pending, and plan cache growth all read as memory pressure and each has a different fix.
2. Find the oversized grant or heavy reader
Section titled “2. Find the oversized grant or heavy reader”One query asking for a large grant can starve everything else. Fix the row estimate that caused the grant, or the access path causing the reads.
3. Review the memory configuration
Section titled “3. Review the memory configuration”Check max server memory, other instances on the host, and whether the plan cache is oversized, before buying more.