SQL Server 2000 内存管理内幕(3)

Address Windowing Extensions

Widnows中的Address Windowing Extensiongs功能允许应用程序存取超过4GB的物理内存。32位的指针是一个整型，只能够存储小于等于0xFFFFFFFF的值，因此只能够引用一个4GB的线性内存地址空间。AWE使应用程序可以突破这个限制，存取所有操作系统支持的内存。

在概念上，AWE并不是一个新的东西，实际上，从计算机诞生开始，操作系统和应用程序就围绕指针限制开始使用类似的机制来处理。例如回到DOS时代，32位扩展（象Phar Lap、Plinks及其它的一些）就普遍运用于16位应用程序，以存取正常地址空间之外的内存。用于扩展内存特殊用途的管理器、API非常普遍。也许你还记得象Quarterdeck QEMM-386这样的产品，在那个时代普遍的用于这类用途中。在这些允许指针存取超过本身表达范围的内存的机制中，具有代表性的方式，是在指针可直接存取的地址空间中提供一个窗口或者是区域，用于和指针无法直接存取的内存区域的转换。这正是AWE的工作原理：在进程地址空间中提供一个区域，或者说一个窗口，用作和user mode的代码无法直接存取的内存区域进行内存存取交换的中专站。

为了使用AWE，应用程序必须：（译者注：下面讲的"需要存取的物理内存"指那些user mode进程在自己的地址空间中无法直接访问到的内存）

1. 使用Win32的AllocateUserPhisycalPages API函数分配要存取的物理内存。该函数需要调用者具有将内存页锁定的权限。

2. 使用VirtualAlloc API函数在进程的地址空间中创建一个区域，作为与需要存取的物理内存进行映射的一个窗口。

3. 使用MapUserPhysicalPages或者MapUserPhysicalPagesScatter API函数，将需要存取的物理内存映射到这个虚拟内存窗口中。

Windows 2000及后续版本支持AWE，尽管可以在低于2G物理内存的机器上使用AWE，但一般只是在2G或者超过2G内存的机器上使用，因为AWE是32位进程存取超过3GB内存的唯一方法。如果你在低于3GB物理内存的系统上，在SQL Server中启用AWE支持，系统会忽略这个选项并使用正常的虚拟内存管理方法。AWE内存一个比较有意思的特性是它不会使用磁盘，你将注意到AWE相关的API函数只对物理内存进行存取，这就是说AWE内存就是物理内存，不会与系统分页文件发生交换。

用于AWE提供的物理内存缓存的虚拟内存窗口，需要具有读、写存取权限，因此当你设置这个虚拟窗口时，传给VirtualAlloc的保护属性只能是PAGE_READWRITE。这也意味着你无法使用VirtualProtect保护这个区域中的内存页，来防止被修改或存取。

注意：你常用的一些检测应用程序内存使用的工具，例如任务管理器、Perfmon/Sysmon等，都无法显示各个进程AWE内存的使用量。并没有什么可以指示各个进程AWE内存的使用量，也就没有什么可以报告给定进程工作区中AWE内存的大小。