What’s the issue?
Lock Pages in Memory (LPIM) is a Windows privilege that, when granted to the SQL Server service account, allows SQL Server to lock its memory allocations so that Windows cannot page them out to disk. It is enabled by granting the “Lock pages in memory” user right to the SQL Server service account through Local Security Policy or Group Policy. Once granted and after a service restart, SQL Server uses the AWE memory allocator and locks buffer pool pages in physical RAM.This finding identifies instances where LPIM is currently in use. It is not necessarily a problem, but it is worth noting in case the team is unaware that LPIM is enabled, or unaware of the operational considerations that come with it.
Why is this a problem?
LPIM was historically recommended to prevent Windows from paging out SQL Server’s working set during memory pressure, which can cause severe performance degradation when buffer pool pages are written to and read from the page file. On servers experiencing this specific problem, LPIM provides a meaningful protection against working set trimming and is still considered a valid configuration choice on dedicated SQL Server hosts.However, LPIM also changes how SQL Server interacts with the operating system in important ways. Locked memory cannot be reclaimed by Windows under any circumstances, so if SQL Server’s max server memory is set too high or other applications on the host need memory, the entire server can become unresponsive rather than gracefully redistributing memory. This makes proper max server memory configuration critical, since the safety net of Windows being able to reclaim memory no longer applies.
Diagnostics and monitoring also behave differently with LPIM enabled. Memory usage reported by Task Manager and Performance Monitor may not reflect SQL Server’s actual consumption, since locked pages are accounted for differently, and troubleshooting memory issues requires looking at SQL Server’s own memory dynamic management views rather than operating system tools.
What should you do about this?
No remediation is required if LPIM is being used intentionally and the team is aware of it. Confirm the current state by checking the SQL Server error log at startup for the message indicating that locked pages are in use, or by running SELECT sql_memory_model_desc FROM sys.dm_os_sys_info; and looking for LOCK_PAGES or LARGE_PAGES.Verify that max server memory is set appropriately, leaving sufficient memory for the operating system and other processes (commonly 75 percent of total memory for a dedicated SQL Server host, with adjustments for very large memory configurations). Because Windows cannot reclaim locked memory, an overly aggressive max server memory setting combined with LPIM can starve the operating system and cause server wide instability.
If the host is virtualized, confirm with the virtualization team that the virtual machine is configured for static memory allocation rather than dynamic memory or ballooning, since these features interact poorly with locked pages and can cause unexpected behavior or service failures. Document the LPIM decision, the service account that holds the privilege, and the rationale for using it.
If the SQL Server service account changes for any reason (password rotation, account replacement, managed service account migration), remember that the LPIM privilege must be granted to the new account, and a service restart is required for the change to take effect. Add this requirement to your service account change procedures so the privilege is not lost inadvertently.