深入SQL SERVER 2000的内存管理机制(二)

可访问大地址的应用 (Large-Address-Aware Executables)

在Windows增加支持/3GB参数以前,一个应用程式是无法访问一个带有高位配置的指针.一个32位的指针只有前31位地址空间能够被用户模式的应用程式访问.这剩余的一位不用.因此有一些聪明的研发者因为其他的目的不愿意在处理内存地址空间时浪费这一位.(举例来说:能够用来标志一个指针引用其他应用程式分配的数据类型).这样就/3GB参数就碰到一个难题,因为这种类型的程式不能方便的区分一个合法的指针引用的内存空间在2G的分界线以上和一个内存地址空间在2G以下,但他的高位已被用做他用的指针.基本上假如一台机器用/3GB的参数启动,这种应用程式是无法运行的.为解决这种状况,微软在WIN32的PE文档Characteristics字段增加了一个新的标志位来表示一个程式是否运行在可访问大地址的(Large-Address-Aware Executables)模式.当该标志位被起用( IMAGE_FILE_LARGE_ADDRESS_AWARE ),该可执行文档头部Characteristics字段的32位被置位.通过这个可执行文档头部的标志位,应用程式能够暗示WINDOWS 他能够处理带有高位配置的指针,这样就不会带来任何异常结果.当该标志被置位并且支持这种方式启动的Windows也是通过/3GB的参数启动,这时操作系统会提供一直扩展的私有用户模式的地址空间给应用程式.您能够通过工具,比如: DumpBin 和 ImageCfg (转储可执行文档的头部)来检查一个可执行文档的该标志位.Visual C 通过 /LARGEADDRESSAWARE 连接器开关来表示IMAGE_FILE_LARGE_ADDRESS_AWARE，SQL SERVR已将该标志位激活,所以您能够在支持/3GB参数的Windows 版本中使用该参数,这样操作系统回自动扩展SQL SERVER的用户内存空间.

注释:Windows在可执行文档启动时检查IMAGE_FILE_LARGE_ADDRESS_AWARE 标志位,但忽略DLL文档.DLL代码必须自动处理高位被置位的指针。

物理内存扩展

Intel 处理器自从Pentium PRO开始，以后的处理器都支持一种物理内存扩展（PAE）的内存映射模式。PAE模式提供了能够访问64GB的物理内存空间。在PAE模式中，内存管理单元（Memory Management Unit (MMU))仍然执行：页目录入口page directory entries(PDEs) 和页表入口page table entries (PTEs),但是在此之上有一个新的级别：页目录指针表。同时，在PAE模式PDEs 和PTEs是64位的（不但仅是标准的32位），这样系统能够映射比标准转换更多的内存空间，因为PDEs 和PTEs模式的寻址宽度是标准的2倍。这并不但仅是增加了页目录指针表。页目录指针表被用来管理这些大容量表和索引。一些特别版本的Windows内核需要运行在PAE模式。这中内核集成在Windows 2000连同以后的版本中，在单处理器的机器中体现在Ntkrnlpa.exe文档中，在多处理器的机器中体现在Ntkrnlpamp.exe文档中。您能够向增加/3GB和/USERVA参数相同在BOOT.INI文档中加/PAE参数激活PAE模式。

地址窗口扩展

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使用和操作起来更加复杂，也更加灵活和可扩展。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有