Currently I am facing a SQL memory pressure issue. i have run dbcc memorystatus
, here is part of my result:
Memory Manager
This is a bit late, but perhaps it will help someone else who reads this.
From seeing Available Virtual Memory
of 8 TB
, I can tell this is a 64 bit system - along with the absence of any references to AWE allocation.
As Lette points out, the OS itself only has 256 MB
of Available Physical Memory
- but that's just what's remaining, not the total amount installed. SQL will try to use as much physical memory that's installed as possible for performance; accessing memory is by far faster than moving a disk head.
Going by VM Committed
, SQL is using 14.1 GB
of physical memory going by VM Committed
- I'll guess that 16 GB total of physical memory is present, accounting for OS needs, available physical memory, and 16 being a good round number.
Memory pressure is coming from two primary areas: SQL buffer pool, and SQL Plan Cache.
SQL Buffer Pool
About 13.5 GB of memory is benig used for the buffer pool. Not atypical for SQL; it will try to use as much memory as it can.
SQL Plan Cache:
Aaccording to 11,382
ad-hoc queries query plans are cached. However, only 28
plans are in use - less than 1%. If we map this back to CACHESTORE_SQLCP, we see an interesting story - no memory is currently being used for these plans at this time, but I think at one point it had consuming 3.24 GB
of memory. I must admit that I'm less sure of this, and would certainly appreciate a 2nd opinion on seeing 0 for VM Commmitted but values present for the allocators.
Summary Since you're running SQL 2008, consider enabling optimizing for ad hoc query plans. This will help quite a bit with memory pressure if your workloads are primarily ad hoc.
Reference