EE_PMOLOCK is recorded when a thread waits for access to a thread-safe memory object used by the query execution engine while allocating certain types of memory during statement execution. The PMO in the name is a partitioned memory object; this is the execution engine’s slice of the same memory-object machinery behind CMEMTHREAD and CMEMPARTITIONED.
Every executing statement does small allocations constantly, so trace amounts of this wait are everywhere.
Is It a Problem?
It has not been a noticeable point of contention in practice, and its normal profile is many tiny waits that never add up to anything. If it ever registers with real time, the reading is the same as for its CMEMTHREAD cousins: some code path is allocating from one shared memory object at extreme frequency, usually meaning a very high statement throughput hammering the same allocation pattern.
Average duration is the honest metric; large counts alone mean nothing.
Common Causes
- Normal execution-time memory allocations across a busy workload.
- Extremely high-frequency, short statements concentrating allocations (chatty applications, per-row calls).
- High core counts amplifying synchronisation on shared objects.
What To Do
- Check the average wait (total time over count); microseconds means ignore it.
- If it genuinely features, reduce the churn: batch chatty per-row calls, improve plan reuse so execution setup work shrinks.
- Read it alongside
CMEMTHREAD; if both rise, the memory-object story is broader than the execution engine.
How To See It
Rank it against everything else with Get-WaitStatistics, judging strictly by average duration rather than count.
Part of the SQL Server Wait Types Library.
Related deep dive: RESOURCE_SEMAPHORE Wait Type.
Leave a Reply