SQL Server memory pressure is easy to suspect and surprisingly easy to misdiagnose. A falling Page Life Expectancy value, a large SQL Server process or a slow query can all look like a memory problem, but each can have a different cause. The safest investigation connects operating-system capacity, SQL Server configuration, memory grants, cache behaviour, waits and the workload timeline before anyone changes a setting.
This guide presents a practical workflow for diagnosing memory pressure. It is designed for production incidents where the first question is not simply “is memory high?” but “which workload or constraint is creating pressure, and what evidence supports the fix?”
Start by separating memory use from memory pressure
SQL Server is expected to use memory. A database engine that has allocated most of its permitted memory is not automatically unhealthy; keeping useful data and plans in cache avoids physical I/O. Pressure exists when the operating system or SQL Server cannot satisfy useful allocations without harmful waiting, paging, eviction or repeated cache churn.
Begin by establishing the incident window and asking:
- Did the whole host slow down, or only one database or workload?
- Was operating-system available memory exhausted?
- Were queries waiting for execution memory grants?
- Did buffer-cache turnover or physical reads rise sharply?
- Did the change coincide with a deployment, maintenance task or reporting workload?
A monitoring history is valuable here because the current state may look normal by the time a DBA opens a diagnostic session. The Mini DBA SQL Server memory monitoring page explains how memory, waits, queries and historical context are kept together.
Check the operating system before changing SQL Server
Review available physical memory, paging activity and the memory used by other processes. If the host is under pressure, confirm whether SQL Server is the main consumer or whether backup software, antivirus, integration services, another SQL instance or an application process is competing for RAM.
Virtual machines add another layer. Verify the memory assigned to the VM, whether dynamic memory or ballooning is involved, and whether the host is under contention. A SQL Server configuration can look reasonable inside the guest while the underlying platform is reclaiming memory.
Validate max server memory in context
max server memory should leave enough capacity for Windows, SQL Server allocations outside the buffer pool, drivers, monitoring agents and every other service on the host. There is no single correct percentage for every server. The right value depends on total RAM, workload concurrency, enabled features and what else runs on the machine.
Do not lower the setting simply because the SQL Server process is large. First establish that the operating system lacks headroom or that another required consumer is being starved. Equally, do not increase it to solve a query memory-grant problem until you know whether a small number of plans are requesting excessive workspace memory.
Investigate query memory grants
Sorts, hashes, index operations and some parallel plans need workspace memory. When requests exceed the memory available for grants, runnable queries can wait even though the database engine already owns a large amount of RAM.
Look for:
- pending or queued memory grants;
RESOURCE_SEMAPHORE waits;- large requested grants compared with memory actually used;
- spills to tempdb in execution plans;
- cardinality errors that inflate row-count estimates;
- several concurrent copies of an otherwise acceptable reporting query.
The corrective action might be query or index tuning, updated statistics, reduced concurrency, a plan correction or more memory. The evidence should decide. Use the SQL Server query view and execution-plan analysis to move from a server-level symptom to the statements responsible.
Read cache indicators as a trend
Page Life Expectancy is most useful as a workload-specific trend, not a universal pass/fail number. A sharp drop combined with rising reads and slower queries can indicate cache churn. A low but stable value on a busy system may be less important than a sudden change from that server's normal range.
Review buffer cache hit ratio, page reads, lazy writes and database-level I/O alongside the workload. If one scan or maintenance operation displaced useful pages, the history should show when it began and which database was active. If cache pressure repeats every day, compare the same period across several days rather than treating each occurrence as an isolated incident.
Correlate waits instead of diagnosing from one counter
Memory pressure often appears through related waits and secondary symptoms. Grant pressure can produce RESOURCE_SEMAPHORE; cache churn can increase physical I/O and storage waits; excessive compilation can put pressure on the plan cache and CPU. The SQL Server waits view helps confirm what the workload was waiting for during the same time window.
A single counter can tell you where to look. A correlated timeline is what lets you explain the incident.
Common mistakes to avoid
- Treating high SQL Server memory use as proof of a leak.
- Using one Page Life Expectancy threshold for every server.
- Increasing memory before reviewing oversized query grants.
- Ignoring other instances and services on the host.
- Looking only at the current state after the expensive workload has finished.
- Changing several settings at once, making the result impossible to attribute.
Validate the fix against the original evidence
After making one justified change, compare the same workload window. Confirm that grant waits, paging, cache churn or query duration improved without creating a new bottleneck. Keep the original baseline so a temporary quiet period is not mistaken for a permanent fix.
Mini DBA retains metric, query and alert history and can use AI-assisted analysis to explain the evidence and suggest practical next checks. You can try the populated online demo or review the SQL Server memory documentation before monitoring your own SQL Server estate.