Why does my SQL Server use AWE memory? and why is this not visible in RAMMap?

We have a Windows Server 2008 R2 (64-bit) 8GB server where, according to Sysinternals RAMMap, 2GB of memory is allocated using AWE. As far as I understood, this means that these pages stay in physical memory and are never pushed out. This causes other apps to be pushed out of physical memory.

In RAMMap, on the Physical Pages tab, the Process column is empty for all of the AWE pages.

We run SQL Server on that box, but (through SQL Server Management Studio, under Server Properties -> Memory, under Server memory options) it says is configured not to use AWE.

However, when stopping SQL Server, the AWE pages are suddenly gone. So it really is the culprit.

So I have three questions:

• Why does RAMMap not know/show that a SQL Server process is responsible for that AWE memory?
• Why does SQL Server Management Studio say that AWE memory is not used?
• How do we make configure SQL Server to really not use AWE memory?

Solution 1:

Does the SQL server account have the "lock pages in memory" option?

In a nutshell, 1) allocating this way is a bit faster and 2) is require for SQL to prevent its memory from being paged out.

Is there a specific reason you don't want SQL to use AWE?

Reference: http://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-530-awe-must-be-enabled-on-64-bit-servers/

• On 64-bit systems (2005+):
• AWE is not required (and in fact enabling it does nothing)
• Turning on the "Locked Pages in Memory" privilege prevents the buffer pool memory (and anything that uses single-page-at-a-time memory allocations) from being paged out
• When the "Locked Pages in Memory" privilege is set, SQL Server uses the Windows AWE API to do memory allocations as it's a little bit faster
• "Locked Pages in Memory" is supported by Standard and Enterprise editions (see this blog post for how to enable it in Standard edition)

See also: Fun with Locked Pages, AWE, Task Manager, and the Working Set… - this explains why setting "use AWE" is false doesn't actually prevent use of AWE (it only is relevant on 32-bit)