SOS_PHYS_PAGE_CACHE

(Republishing, or using this info in a commercial product/website, is prohibited without permission. All other uses are permitted. If in doubt, please ask.)

(Back to main page…)

Description:

This wait type is when a thread is waiting for access to the portion of the SQL OS memory manager that allocates or releases memory from/to Windows. These generally occur on 64-bit servers when the instance is using locked pages in the buffer pool (i.e. the service account has the SeLockMemoryPrivilege privilege set).

(Books Online description: “Accounts for the time a thread waits to acquire the mutex it must acquire before it allocates physical pages or before it returns those pages to the operating system. Waits on this type only appear if the instance of SQL Server uses AWE memory.”)

Questions/comments on this wait type? Click here to send Paul an email, especially if you have any information to add to this topic.

Added in SQL Server version:

2012

Removed in SQL Server version:

N/A

Extended Events wait_type value:

The map_key value in sys.dm_xe_map_values is 129 in 2012 and 2014 RTM. After 2014 RTM, you must check the DMV to get the latest value as some map_key values have changed in later builds.

Other information:

I have not seen this wait type be a noticeable contention point under normal circumstances. There was a bug on NUMA systems with SQL Server 2012 and SQL Server 2014 that could cause this wait type to become very high – see here for the KB article and details of which builds contain the fix.

Known occurrences in SQL Server (list number matches call stack list):

1. Allocating memory (in this case, while processing pages during the fact generation stage of DBCC CHECKDB)
2. Releasing memory (in this case, as part of the background SQL OS resource monitor responding to memory pressure)

And many other similar call stacks.

Abbreviated call stacks (list number matches known occurrences list):

1. UnfairRecursiveMutexInternal<SuspendQueueSLock,0>::LongWait+1ad
   TAutoMutex<UnfairRecursiveMutexInternal<SuspendQueueSLock,0>,4294967295>::GetAccess+103
   PhysicalPageCache::AllocatePhysicalPages+be
   MemoryNode::AllocateUserPhysicalPages+44
   SOS_MemoryBlockAllocator::CommitBlockAndCheckNumaLocality+60a
   SOS_MemoryBlockAllocator::AllocateBlock+5d7
   SOS_MemoryWorkSpace::AllocatePage+270
   MemoryNode::AllocatePagesInternal+187
   MemoryClerkInternal::AllocatePages+be
   BPool::Steal+35a
   BPool::GetFromDisk+234
   MultiObjectScanner::GetNextPageAndReadAhead+3bb
   MultiObjectScanner::GetNext+98
   MultiObjectScanner::GetNextPageAndBatch+26f
   CheckTables::ProcessNextData+1ad
   CheckAggregateSingleInstance::GetNextFact+247
   CTRowsetInstance::FGetNextRow+3c
   CUtRowset::GetNextRows+a0
   CQScanRmtScanNew::GetRowHelper+3b5
   CQScanXProducerNew::GetRowHelper+366
   CQScanXProducerNew::GetRow+15
2. SOS_Task::PostWait+90
   UnfairRecursiveMutexInternal<SuspendQueueSLock,0>::LongWait+1ad
   TAutoMutex<UnfairRecursiveMutexInternal<SuspendQueueSLock,0>,4294967295>::GetAccess+103
   PhysicalPageCache::FreePhysicalPages+50
   SOS_MemoryWorkSpace::DeCommitBlock+220
   MemoryNode::ReleaseAwayBlocks+d5
   MemoryNode::ReleaseAwayBlocksOnAllNodes+5a
   MemoryNode::ShrinkIfNecessary+bf
   ResourceMonitor::CheckIndicators+12c
   ResourceMonitor::ResourceMonitorTask+223
   SetupResourceMonitorTaskContext+105
   SOS_Task::Param::Execute+21e
   SOS_Scheduler::RunTask+a8