深入SQLServer 2000的内存管理机制（二）

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

为了使用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内存是不和系统的虚拟页面文件交互物理内存空间。

dedecms.com

增加用户程序地址空间的能力几乎有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使用和操作起来更加复杂，也更加灵活和可扩展。

看完这篇，您有何感觉呢？