遭遇"thrashing"
Thrashing的中文翻译叫"颠簸"吧，听着挺怪的，其实也是，很多技术名词都是可意会而不可言传的。
反正就是这么回事吧，当你的物理内存不够用时，之后每从pagefile读入多少内容，就需要先从内存中腾出多少空间写到pagefile先。这一读一写就会让你的系统元气大伤，而且，如果物理内存迟迟得不到释放，之后所有涉及到page fault的操作都会经历这一读一写，结局就是每步操作都慢如蜗牛。
其实，此时系统已经处于相当不稳定的状态，学名"Thrashing"。
Thrashing这个概念在大学操作系统的课程里学过，在一些性能相关的书或者文章中也看到过，但要说这寸步难行的真实经历，倒还真没有过。我想原因有二吧，一是现在的硬件这么便宜，内存一般还是够用的；二是我不是那种会在同一时刻打开无数程序的人，即使有的时候感觉系统有些慢了，也会赶紧关掉一些，自然避免了thrashing。
然而今天竟然让我在一台双核4G内存的电脑上，感受了一把系统"颠簸"时生不如死的感觉~~~
现象
我用 ProcMon这个工具观察程序加上我的代码之后的行为，觉得没问题之后，打算在本地做的full build，于是启动IncrediBuild就Build了起来，同时我自己也转到了另一台机子上继续工作 --- 我们的代码，一个full build，没有4个小时是搞不定的。
若干个小时后，我回到那台电脑去看看情况：悲剧发生了，鼠标以极其缓慢的速度从屏幕上划过，在任务栏上点了下IncrediBuild的图标之后，也是迟迟没有反应。接下来，我的所有操作都是按照"16X慢进"的速度进行的~~~
猜测
第一个怀疑的当然是IncrediBuild了，因为主要就是它在做事。打开procexp查看，没有CPU占用率很高的进程啊。我知道IncrediBuild的磁盘操作会比较多，但其磁盘操作也不至于影响到系统至这个地步~~~
Ctrl+I打开procexp的系统信息对话框看了一下，注意到物理内存使用量接近4G，满负荷操作。此时我大概明白， 应该是遭遇了对我来讲百年不遇的"thrashing"了。可是为什么在这短短的几个小时内，物理内存使用量会急剧飙升到4G呢，难道IncrediBuild有内存泄露？ 这得多大的泄露啊，不要说这不可能，即便如此，这些泄露的内存在一段时间不用之后，也会被交换到pagefile，而不是把物理内存塞满，Windows的内存管理器还不至于傻成这样。
分析
然后，我在系统信息框中看到了类似于下面的信息：
何以Commit Charge值达到16G之巨(pagefile + memory)? 一般情况下，只是有个3G，5G而已。在此过程中我并没有打开任何新的程序，即使所有原来打开的程序的private bytes全写到pagefile，也不会有这么多，更何况物理内存现在也是满负荷运转的。
很明显，有人在搞鬼，在不停的往pagefile里写数据。细细一回想: ProcMon! 果然，发现在默认情况下，它会将其捕捉到的事件信息写到pagefile中去：
至此，可以推断大概发生了什么事：
- ProcMon不断的向pagefile写数据，而且数据量巨大。
- pagefile的size不断动态调整，直到达到极限 = 4G*3. (参见Pushing the Limits of Windows: Virtual Memory)
On Windows Vista and Server 2008, the minimum is intended to be large enough to hold a kernel-memory crash dump and is RAM plus 300MB or 1GB, whichever is larger. The maximum is either three times the size of RAM or 4GB, whichever is larger.
- 然后，物理内存被不断推高，猜测原因如下：
- ProcMon试图继续往pagefile中写数据，无奈pagefile已满，于是就像内存满了会往pagefile写一样，pagefile满了，也会向内存转移，于是，内存也被写满。
- 或者，当pagefile被写满后，IncrediBuild无法将其使用的内存交换至pagefile，导致物理内存不断上升直到被写满。
- 物理内存满负荷，开始颠簸ing~~~
结论
使用ProcMon这种会往pagefile中没完没了写东西的程序一定要小心，用完及时关闭（此时其占用Commit Charge会马上释放）或者设置成写到一个独立的文件中。
