Buffer Pool Pressure

Category: Memory · Also known as: Page life expectancy drop

Pages are leaving the buffer pool much faster than usual (Page Life Expectancy is falling) - large reads are evicting cached data, so more queries have to go to disk.

What this finding means

Page Life Expectancy, the average time a data page survives in the buffer pool before being evicted, dropped well below its normal level. Falling PLE means pages are being read in faster than they are being reused, so the cache is churning and an increasing share of reads is going to disk instead of memory.

Why it matters

Memory is the cheapest storage in the system, and buffer pool churn is the mechanism by which a query problem becomes a storage problem. Once the working set no longer fits, physical reads climb, storage latency climbs behind them, and unrelated queries slow down. This finding is frequently the midpoint of a causal chain rather than either end of it.

How WISdom detects it

The Buffer Manager Page Life Expectancy performance counter is read from sys.dm_os_performance_counters each minute and compared to the four-week maximum for this minute-of-day. Lower is worse for this counter, so the delta is inverted relative to most rules. This rule is always evaluated and returns a value every minute.


Collected from	Performance counter Buffer Manager: Page life expectancy (sys.dm_os_performance_counters).
Compared with	Max value 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

Current PLE in seconds against the History max for this minute-of-day. Ignore the old 300-second rule of thumb; it predates modern memory sizes and is meaningless on a large buffer pool. What matters is the shape against this instance’s own history. A cliff aligned to one minute points at a single statement; a slow slide across the hour points at growing working set.

What normally causes it

A large scan pulling a table through the buffer pool and evicting everything else.
A query with a bad row estimate reading far more pages than it needs.
Index maintenance, a backup, or a consistency check running inside the workload window.
A working set that has genuinely outgrown the memory allocated to the instance.

What this finding is not

Not a memory shortage on its own. PLE falling because one bad scan ran is a query problem that memory would only mask.
Not comparable across instances. PLE scales with buffer pool size, so an absolute number means nothing without this instance’s own baseline.
Not meaningful on a NUMA system read as a single value without also checking per-node PLE, where one node can be starved while the aggregate looks healthy.

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. Cut the read volume

Pages are being evicted because something is pulling too many in. Find the high-read statements and fix the access path. Fewer reads is the only free fix here.

2. Look for a competing memory consumer

A large memory grant, an oversized plan cache, or another instance on the same host can squeeze the buffer pool. Confirm that before blaming the workload.

3. Add memory

Only when the reads are legitimate and sustained. Size it from the working set, not from the lowest page life expectancy you have seen.