1. commit limit与current commit charge

接上文，我们看到testlimit -r开关，只是预留虚拟内存，并没有实际进行提交(commit)。预留虚存并不存储数据或代码，但有时候应用需要这个预留（就像预订坐位一样），用以创建大块虚存，并且在需要的时候进行提交，以确保提交的内存在地址空间上是连续的。当进程提交一块虚存时，操作系统要确保存储在内存里的数据要么全部在内存里，要么全部在硬盘中。这意味着进程的运行有另外一个限制：commit limit。

commit limit是物理内存和页文件大小的总和。事实上，并不是所有物理内存被计算在内，因为操作系统预留了一部分给自己使用。所有存活进程提交的虚存的总和，称之为current commit charge，它不能超过系统的commit limit。当commit limit值达到时，虚存的分配就会失败。这意味着标准的32位进程，在达到2GB地址空间限制之前，有可能会出现虚存分配失败。

current commit charge和commit limit由进程管理器来跟踪，其数据显示如下图：

在Vista和Win2008之前的版本，可能显示的不叫current commit charge和limit，而采用的是current commit change ("PF Usage")，实际上就是page file usage:

在Vista和win2008下，任务管理器不显示commit　charge图，只给出current commit charge和limit值，表示为"Page File"

你可以使用Testlimit -m 来对commit limit进行压力测试，让它强行分配已提交内存。32位版本的Testlimit在达到commit limit之前可能不会碰到地址空间的级限，这要依赖于物理内存的大小、虚存页文件的大小以及current commit charge值的大小。如果在32位windows下运行，并且要看看在达到commit limit时系统的行为，可以多运行几个Testlimit实例，直到有一个在用尽地址空间之前，达到commit limit。

注意，缺省情况下，页文件是动态增长的，那意味着commit limit也会动态增长（在commit charge变大并且接近它时），并且，即使页文件达到它的最大值，系统也会放掉部分内存，进行内部调节，就如同普通的应用程序缓存完数据以后，会放掉一部分内存一样。Testlimit在达到commit limit之后，会sleep几秒钟，接着尝试分配更多内存，不断重复，直至被强行终断。

如果你运行的是64位的Testlimit, 几乎可以肯定的是，在用尽地址空间之前，它就会达到commit limit，除非物理内存和页文件大小加起来能超过8TB，这个8TB在第一节里，已经描述了，它是64位应用可以访问的地址空间。这里是64位Testlimit在8GB内存的系统上（指定每次分配100M）的运行过程中的部分结果：