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

SOS_PHYS_PAGE_CACHE

(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