SOS_PHYS_PAGE_CACHE is a wait on the mutex a thread must hold before allocating physical memory pages from Windows or returning them. It shows up on instances using locked pages in memory, that is, when the service account holds the SeLockMemoryPrivilege right (Lock Pages in Memory), because that allocation path goes through this guarded cache.
Seeing the wait at all mostly confirms your memory configuration: LPIM is active.
Is It a Problem?
Under normal circumstances, no. Allocations pass through the mutex quickly and the wait stays in the noise. It earned its reputation from one specific defect: on NUMA systems running SQL Server 2012 and 2014, a bug could drive this wait very high, and the fix shipped in later cumulative updates. If you are on one of those versions and this wait ranks highly, patching is the answer, not tuning.
Outside that bug, sustained visibility here means the instance is aggressively acquiring or releasing physical memory, which is itself worth understanding.
Common Causes
- Normal LPIM-path allocations, small and quick.
- The known NUMA bug on unpatched SQL Server 2012/2014 builds.
- Memory thrash:
max server memoryset so the instance repeatedly grows and shrinks its working set, churning physical page allocations.
What To Do
- Check your build if you are on 2012/2014 on NUMA hardware; apply the CU containing the fix.
- Stabilise memory: set
max server memoryto a value the box can actually sustain so SQL Server is not constantly negotiating pages with Windows. - Confirm LPIM is intentional (it usually should be on dedicated servers) and that memory pressure indicators are otherwise healthy.
How To See It
Rank it against everything else with Get-WaitStatistics. On patched builds with stable memory settings it should barely register.
Part of the SQL Server Wait Types Library.
Related deep dive: RESOURCE_SEMAPHORE Wait Type.
Leave a Reply