Wilfred van Dijk (5/28/2008)

---

If you don't enable AWE on a 64bit server you can get errors like "A significant part of sql server process memory has been paged out. This may result in performance degradation". for example, this can happen if you copy a lage filebackup to another server.

As a result, al your SQL processes are suspending, but I would say dying (I've had that experience) :blush:

Read the following articles:

http://blogs.msdn.com/psssql/archive/2007/05/31/the-sql-server-working-set-message.aspx

http://support.microsoft.com/kb/918483

http://msmvps.com/blogs/omar/archive/2007/09/19/a-significant-part-of-sql-server-process-memory-has-been-paged-out-this-may-result-in-performance-degradation.aspx

http://www.mcse.ms/message2444910.html

http://blogs.msdn.com/slavao/archive/2005/04/29/413425.aspx

Although AWE makes execution of memory-intensive applications possible when otherwise impossible, AWE imposes overhead, adds initialization time, and can face performance challenges under various processing conditions. These issues are eliminated on the 64-bit platform when directly addressing memory.

...

...

AWE does not increase Virtual Address Space

A 32-bit system limits the virtual address space (the address space used by Windows to manage memory allocations) to 2 GB. Since AWE does not eliminate this virtual address space (VAS) limitation, many users try to raise the ceiling for this 32-bit limitation of only 2 GB of VAS by using the /3GB switch in the boot.ini file. This increases the VAS to 3 GB, thereby leaving only 1 GB for the operating system. This results in the reduction of the addressable physical memory of a single instance of Windows Server 2003 Enterprise and Datacenter editions to 16 GB. When not using the /3GB switch on Windows Server 2003 Enterprise Edition, the maximum memory addressable is 32 GB. For the Datacenter edition, it is 64 GB. This is because Windows requires more than 1 GB of VAS to manage more than 16 GB of total physical memory in one instance. So, using the switch may impose an artificial ceiling, thereby diminishing the capacity of your hardware and operating system.

For all practical purposes, the use of AWE in a 32-bit environment is only for data caching. This is because data pages use relative addressing (a requirement for AWE usage), while other components do not. Consequently, other components, operating within a relatively small VAS of either 2 or 3 GB could be significantly blocked in larger systems that have complex workloads or many concurrent users even when running on high end servers with abundant memory.

For example, the plan cache (cache of query plans) in SQL Server 2005 resides in the VAS. In cases of VAS memory pressure, query plans and execution contexts with costs of zero (0) are deleted from the plan cache. In high transaction environments, this could lead to poor performance due to the time and CPU resources that are needed to compile the query plans again. Conversely, on 64-bit systems, VAS is, for all practical purposes, unlimited. The result is faster performance because no additional time is taken up re-creating a query plan. This results in less CPU loading since the CPU is not working to compile a new plan as frequently. Such incidences can occur even on servers with large amounts of memory (such as 8 GB or more) because the plan cache (and other components except data pages) cannot take advantage of AWE memory.

Another example of the limitations of AWE concerns support in SQL Server 2005 for the common language runtime (CLR). Although the CLR uses some memory allocations from the buffer pool (single-page allocator) where AWE is most useful, most SQL Operating System (SQLOS) memory allocations (multipage allocator) on behalf of the CLR are from the VAS. For customers who are considering more than moderate use of the CLR within SQL Server 2005, an additional reason to adopt 64-bit would be to prevent loss of performance from VAS memory pressure.