Three sleep waits share the theme of “no free memory right now, nap and retry”, and this page covers them together:
SLEEP_BPOOL_STEAL: a free list stall. A new page is needed but the buffer pool has no free memory, so the thread sleeps briefly (historically ~10ms) expecting the lazy writer to free something. Each occurrence blips theBuffer Manager: Free list stalls/seccounter.SLEEP_BUFFERPOOL_HELPLW: a thread helping the lazy writer under memory pressure with a heavy read/write workload; when enough writes are already in flight, the helper waits and loops instead of issuing more.SLEEP_MEMORYPOOL_ALLOCATEPAGES: a thread needing memory with none available, waiting briefly for the system to free some.
Individually benign; collectively a memory-pressure gauge.
Are They a Problem?
Occasional traces, no. A rising trend, yes, in the informative sense: these waits increasing means threads are routinely finding the free list empty, which is buffer pool memory pressure with a paper trail. The Free list stalls/sec counter corroborates SLEEP_BPOOL_STEAL directly, and page life expectancy dips usually accompany the picture.
On a workload already known to be memory-tight and otherwise tuned, SLEEP_BUFFERPOOL_HELPLW is a normal fixture; growth beyond the baseline is the signal.
What To Do
- Confirm with the counters:
Free list stalls/sec,Lazy writes/sec, and page life expectancy trends. - Address the pressure:
max server memorysanity (and what else on the box squeezes SQL Server), and the query-side fixes that shrink the working set, missing indexes turning scans into seeks being the perennial biggest lever. - If the hardware is simply undersized for the working set, more RAM is the honest answer.
How To See It
Rank the family with Get-WaitStatistics, and treat its trend, alongside the Buffer Manager counters, as your memory-pressure early warning.
Part of the SQL Server Wait Types Library.
Related deep dive: PAGEIOLATCH_SH Wait Type.
Leave a Reply