SQL Server 2000 内存管理内幕(4)

/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更难于使用和存取，但它更具弹性和扩展。

并不是说任何情况下AWE都比/3GB好，只是通常状况下是这样。比如说当你需要很多空间以分配内存，而又不能放在AWE内存中（例如象线程栈Thread Stacks、锁内存Lock Memory、存储过程计划Procedure Plans等），你也许会发现/3GB更合适。

Memory Regions

SQL Server将分配的内存组织成两个独立的区域：BPool和MemToLeave。实际上如果你使用AWE模式，还有另外一个区域：在Windows AWE支持下可以存取的3GB以上的物理内存。

BPool在这三个区域中是比较突出的一个，它是SQL Server主要的分配池，主要用于数据和索引页的缓存，也用于小于8K的内存分配。MemToLeave包含user mode地址空间中BPool没有使用的那部分虚拟内存空间。3GB之上的AWE内存作为BPool的扩展，为数据和索引页缓存提供额外的空间。

当你启动SQL Server的时候，SQL Server基于机器的物理内存和user mode地址空间的大小计算BPool的上限。在计算出这个值后，MemToLeave区域被保留，这有利于防止BPool随后的预留造成内存碎片。接下来，BPool被保留，它可以分成多达32个独立预留块，用于满足在BPool保留时SQL Server进程中那些正在请求虚拟地址空间的dll及其它分配请求。在保留BPool区域之后，MemToLeave区域被释放。MemToLeave用于SQL Server内部超过8KB的连续空间分配请求，以及象OLEDB Provider、进程内COM对象等外部客户（指SQL Server主要引擎之外，驻留在SQL Server进程中的那些内存请求者）分配请求。

因此，一旦SQL Server启动，BPool就被保留，但未被提交，MemToLeave基本就是进程的虚拟内存地址空间中的空闲部分。如果你在SQL Server启动之后查看SQL Server进程的Virtual Bytes Perfmon计数器，你将发现它反映的是BPool的预留。我曾经看到人们因为这个数字经常很高而惊慌，毕竟，它通常是机器总的物理内存或者是最大user mode地址空间，减去MemToLeave区域大小。这没什么担心的，因为它仅仅是保留但没有提交的空间。之前提到过，保留的空间仅仅是一个地址空间，直到被提交时才会真正的和物理存储单元关联。在这些之后，被提交到BPool中的内存将会增加，直到达到SQL Server启动时计算出的BPool上限值。

Monitoring SQL Server Virtual Memory Use

你可以通过SQL Server:Buffer Manager\Target Pages Perfmon计数器跟踪计算出的BPool最大值。SQL Server不同部分需要内存时，BPool提交一开始就被保留的8KB大小的页直到达到计算的上限值，你可以通过SQL Server:Buffer Manager\Total Pages Perfmon计数器跟踪BPool中被提交的虚拟内存的使用状况。另外你可以通过Private Bytes计数器跟踪SQL Server进程中所有被提交的虚拟内存的使用状况。