深入SQL SERVER 2000的内存管理机制（3）

地址窗口扩展

Windows的地址窗口扩展（AWE）机制可以允许应用程序访问超过4GB的物理内存。一个32位的指针是一个整数，只能保存0x00000000到0xFFFFFFFF的值，就是说可以引用4GB 以内线性的内存地址空间，AWE允许一个应用程序绕过这些限制，通过操作系统访问所有的内存空间。

从概念上说，AWE并不是一个新的事物。在计算机发展之初，操作系统和应用程序已经使用相似的机制回避指针的限制。例如：我们倒退到DOS年代，32位扩充功能被经常用来允许一个16位的程序访问他自已以外的内存地址空间。一些特殊目的管理者和API经常使用扩充内存和扩展内存。你可能记得这样一个很久以前产品Quarterdeck QEMM-386经常用来做这样的事情。典型的机制是允许一个指针可以访问超过本身限制的空间，（比如：地址太大无法在自己的指针中）通过在可以访问的地址空间分配一个窗口或区域来和本身无法访问的内存地址之间传递指针。AWE的工作原理：你可以在可以访问的地址空间提供一块区域（窗口）作为分段传输区，来传送在用户内存空间无法访问的内存地址。

为了使用AWE，一个应用程序需要：

1．               分配的物理内存地址可以通过AllocateUserPhysicalPages  API函数访问。这个函数需要调用者有Lock Pages in Memory的权限。

2．               在可以访问的内存空间建立一块区域。通过VirtualAlloc API函数可以作为映射一个物理内存的映射窗口。

3．               通过MapUserPhysicalPages 或MapUserPhysicalPagesScatter WIN32 API 函数完成物理内存和虚拟内存的映射。

AWE已经存在于所有的Windows 2000和以后的操作系统中,甚至可以用于物理内存低于2GB的操作系统中，最典型的应用是在2GB或以上物理内存的机器上，因为这是一个32位处理器访问3GB以下内存空间的唯一方法。如果你在一个低于3GB物理内存的SQL Server系统中激活AWE支持，系统将忽略这个选项同时转换为虚拟内存管理器代替。AWE内存有一个有趣的特征就是从不和磁盘交换数据。你也许注意到特有的AWE API程序引用可以访问的内存空间是作为物理内存访问。这点确切的说就是：AWE内存是不和系统的虚拟页面文件交互物理内存空间。

虚拟内存窗口被用来缓存AWE读写访问物理内存的请求。因此，当你配置这个窗口是PAGE_READWRITE唯一可以保护的特征就是转嫁给了VirtualAlloc API函数。不要惊奇，这也意味你不能用VirtualProtect API函数来保护这块内存区域的修改和访问。

注释:还没有专门的工具用来调查应用程序AWE内存使用（任务管理器，性能监视器和监视系统 等等），显示每一个程序AWE内存的使用数量。这样就没有每个程序使用AWE内存数量的轨迹，同时这些内存也没包括在每个的程序的工作内存集中。

/3GB 和AWE比较

     增加用户程序地址空间的能力几乎有50％的应用程序是通过内存调整，这是在Windows内存管理机制当中非常快捷和受欢迎的手段。而且Windows AWE内存机制也是非常灵活和稳定的。就像我前面所说的，当你增加1G的用户内存空间，这些内存是通过减少核心内存空间获得的（从2G减到1G）。因为核心代码的运行对整个内存空间来说是很狭窄的一块即使用于2G的空间，收缩这些内存空间意味着内部核心架构也会收缩。其中最重要的是windows用来管理物理内存的表,当你收缩核心内存空间到1G，你就限制了这个表的大小，这样只能管理最大16GB的物理内存。例如：如果你的应用程序运行在有64GB物理内存的SERVER上并且你在启动时加了/3GB的参数。你只能访问整个内存的25％的空间—其余的48GB的内存空间无论时操作系统还是应用程序都无法访问。AWE可以允许你访问比加/3GB参数更高的内存空间。显然，你通过/3GB的参数只是增加了1GB的用户内存空间，这些增加的内存空间只是对那些大地址自动获得的应用程序有效，但是只有1GB。和/3GB参数对比，AWE可以使整个的物理内存对操作系统有效和对使用AWE WIN32 API的应用程序有效。因此，AWE使用和操作起来更加复杂，也更加灵活和可扩展。

   着并不是说/3GB比AWE更好是不存在的－不过这确实存在，比如：如果你需要分配更多的内存空间，但不能在AWE中分配（线程堆栈，内存锁，过程计划），你也许发现/3GB回更好一些