Q and A: Some questions about output from dbcc memorystatus


Recently I have recieved following question:  A customer of mine is getting this output on an Itanium with 16GB of memory:


Memory Manager                      KB


—————————— ——————–


VM Reserved                           16979888


VM Committed                         217928


AWE Allocated                         14116272


Reserved Memory                     1024


Reserved Memory In Use            0


 


Q. How can VM Committed be so much less than AWE Allocated, or is this counter broken when Lock Pages are used?


 


A. The counter is not broken. The output above shows what API SQL Server uses to allocate physical memory. When you enable SQL Server to use AWE mechanism to allocate physical memory, SQL Server will use AWE API to allocate memory for majority of its allocations, i.e. for Buffer Pool. (Please don’t forget that Buffer Pool acts as preferable memory manager for dynamic allocations) When SQL Server uses AWE mechanism, you will see increase for AWE Allocated and drop in VM Committed since SQL Server no longer uses VirtualAlloc (…,MEM_COMMIT,…) to allocate physical memory for Buffer Pool. 


 


Q. Also, in the memory clerks, I find


MEMORYCLERK_SQLQERESERVATIONS (Total) KB


—————————————— ——————–


VM Reserved                                            0


VM Committed                                          0
AWE Allocated                                          0


SM Reserved                                            0


SM Commited                                           0


SinglePage Allocator                                  8184408


MultiPage Allocator                                    0


 


What are SQLQERESERVATIONS?  Do they represent workspace memory in use?


 


A. This is a reservation clerk. It represents how much memory has been allocated by Query Execution out of reservation performed earlier to run queries. You can look at memory broker output for reservations in dbcc memorystatus to find out how much memory is actually reserved.


 

Comments (4)

  1. jaipal says:

    good post

  2. Joe Chang says:

    why is the AWE API used in 64-bit, Itanium or EM64

  3. slavao says:

    On 64 bit platforms we should have renamed AWE Allocated to Locked pages allocated. Please take a look at my previous post: http://blogs.msdn.com/slavao/archive/2006/03/13/550594.aspx,