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

因为SQL Server中绝大部分虚拟内存的使用都来自BPool，因此通常情况下，这两个计数器将一前一后的增加或平稳下来（记住，当启用AWE支持后，Private Bytes计数器不会反映SQL Server全部的内存使用）。如果Total Pages计数器平稳下来，而Private Bytes持续增加，这通常表明MemToLeave区域中连续的内存分配。这种内存分配可能比较常见，例如可能是SQL Server创建额外的工作线程时和线程栈相关的内存分配，或者是进程内COM对象、扩展存储过程等外部请求者的内存泄漏等。如果由于内存泄漏或者内存使用过大，导致MemToLeave区域耗尽，使SQL Server进程用完了虚拟内存地址空间的内存（或者是MemToLeave区域中的最大空闲块低于0.5M的默认进程栈大小），就算是并没有达到使用sp_configure配置的最大工作进程数，SQL Server将无法创建新的工作进程。这种情况下，如果SQL Server需要创建一个新的工作进程来执行一个工作请求，例如处理SQL Server新的连接请求等，那么这个工作请求将被延迟，知道服务器有足够的资源创建工作进程，或者是其它工作进程被释放出来。这可能会导致用户无法连接到服务器，因为在从MemToLeave中获得足够的空闲空间或者是其它工作进程被释放能够处理当前工作请求之前，连接可能会超时。

Allocations

SQL Server中的内存请求者在初始化内存请求时，先创建一个内存对象管理当前的请求，当内存对象执行请求时，它调用SQL Server中相应的内存管理器从BPool或者是MemToLeave区域获取内存。请求小于8KB时，通常从BPool中获取内存；当请求8KB或者更大的连续空间时，通常从MemToLeave区域中获取。因为一个内存对象可能会产生多个分配请求，因此有可能会从MemToLeave区域中分配小于8KB的分配请求。向SQL Server进程空间请求内存一般情况下都是内部请求者，就是说SQL Server的内部对象需要内存以执行某个任务，当然不是绝对的，象上面提到过的也有可能是外部请求者。通常，这些外部请求者使用Win32内存API函数分配和管理内存，因此是从MemToLeave区域中分配，因为（对于操作系统而言，译者注）SQL Server进程中只有MemToLeave区域可用（BPool区域被SQL Server保留，译者注）。但对于扩展存储过程是个特殊情况，扩展存储过程调用ODS的srv_alloc API函数实现，这使得它同SQL Server内部请求者被同等的处理，通常srv_alloc请求小于8KB的内存时从BPool中分配，大的内存分配则来自MemToLeave区域。

The Memory Manager

服务器运行时，内存管理器进行检查，以确保为服务器预留了一定数量的可用物理内存，使Windows和服务器上其它应用程序能够继续平稳的运行。这个数量从4M到10M左右（Windows Server 2003上接近10M），基于系统负载和BPool中内存页生命期得出。如果服务器上可用物理内存开始低于这个极限值，服务器释放BPool中的部分内存页，以收缩BPool的内存使用量（假设SQL Server的动态内存配置被启用）。内存管理器也确保任何时候保留了一定数量的空闲内存页，以使新的分配请求到达时，不必等待内存分配。这里的空闲，意思是指这些内存页被提交了，但是未使用。被提交但未被使用的BPool内存页通过一个空闲列表跟踪，当列表中的页被使用时，内存管理器从BPool的预留中分配更多的内存页，直到整个BPool预留被提交。你将看到Process:Private Bytes Perfmon计数器由于这个行为而逐渐的增长（通常是线性增长）。

系统中对应每一个CPU都有一个单独的空闲列表，当需要使用空闲页用于满足一个分配请求时，先检查和当前分配请求CPU相关的空闲列表，然后再检查系统中其它CPU相关的列表。这在多处理器系统上，有利于各个处理器更好的使用本地缓存，提高扩展性。你可以使用SQL Server:Buffer Partition Perfmon计数器监控特定的BPool分区，通过SQL Server:Buffer Manager\Free Pages Perfmon计数器监控所有分区的空闲列表。