How to analyze 'dbcc memorystatus' result in SQL Server 2008

Question

Currently I am facing a SQL memory pressure issue. i have run dbcc memorystatus, here is part of my result:

Memory Manager                               


        

Answer 1

Here's a guess:

One thing that strikes me is that you have a Working Set of 15 GB while the Available Physical Memory is only 258 MB. I believe you should make more memory available to Sql Server. (Whether that's just moving a slider a little more to the right, and/or installing more RAM, I couldn't know.)

Answer 2

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

Answer 3

The docs for DBCC MEMORYSTATUS() are here: http://support.microsoft.com/kb/907877

They're not terribly verbose - but will, at least, give you an idea of what you're looking at.