深化SQL SERVER 2000的内存管理机制(二)[MSSQL防范]

可拜候大地址的利用 (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利用和操作起来越发复杂,也越发机动和可扩大.

?? 着并非说/3GB比AWE更好是不存在的－不过这确切存在,比方:假如你需求分配更多的内存空间,但不能在AWE中分配（线程仓库,内存锁,历程筹划）,你大概发现/3GB回更好一些. 　　以上是“深化SQL SERVER 2000的内存管理机制(二)[MSSQL防范]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：