SQL Server 2000内存管理内幕

核心提示： 为了使用AWE，应用程序必须：（译者注：下面讲的"需要存取的物理内存"指那些user mode进程在自己的地址空间中无法直接访问到的内存） 1. 使用Win32的AllocateUserPhisycalPages API函数分配要存取的物理内存，SQL Server 2

为了使用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内存的大小。

/3GB vs AWE

在Windows的内存管理功能中，Application Memory Tuning（/3GB）可以给私有进程增加50%的地址空间，使用方便，因此成为一种常用方法，但AWE功能更具有弹性和扩展性。前面提到，当你为私有进程地址空间增加1GB，这1GB来自kernal mode的地址空间，kernal mode地址空间也由2GB被压缩到1GB。对于kernal mode代码，完整2GB的工作空间已经显得狭窄，压缩这部分空间意味着某些内部核心结构也必须要压缩。这些结构中主要有机器上用于管理内存的表窗口（table Windows）。当你将kernal mode部分压缩到1GB后，这个表最大就只能管理16GB的物理内存了。例如你在一台具有64GB物理内存的机器上运行Windows 2000 DataCenter，启动时使用了/3GB选项，你就只能够存取这台机器25%的内存，剩余的48BG将无法被操作系统和应用程序使用。AWE允许你访问超过3GB的内存，而通过/3GB，你仅仅为私有进程空间获得额外的1GB。Large Address Aware自动透明的使得这个额外空间对应用程序可用，但它被限制在1GB之内。理论上，AWE通过Win32 AWE API函数，使得所有对操作系统可用的物理内存对应用程序可用。尽管AWE更难于使用和存取，但它更具弹性和扩展。