不久前我发现了非常有趣的工具RamMap 。 我在运行我们的x32软件的几台服务器上发现，PAGE TABLE增长非常快 – 每天1.2 GB（全部10 GB）。 另外NONPAGED POOL每天增长300MB。
我们有编程和执行平台称为1C（俄罗斯商业导向平台）。 一个过程就像一个pipe理员，按照计划启动，被规则终止，执行不同types的数据处理，包括使用COM与其他数据库交换数据。 换句话说，我不能告诉平台级别发生了什么事情（它对我们来说是隐藏的）。 我们对平台开发人员有一些不太快（=）的支持 – 他们仍然没有回答我们对这个问题的疑问。
我们有不同的操作系统configuration（2003和2008服务器，x32和x64）。 到处都是页表增长。 增长速度与同时运行的进程数量（主服务器30-40）成正比。 当PAGE TABLE达到50-70％的RAM服务器开始以不同的方式失败。
看起来像虚拟内存碎片问题; 内存不断分配和释放，并且每次创build新的页面表项（PTE）以便跟踪内存页面; 你的断言，正在创build和终止大量的进程，并且这个页表增加与正在运行的进程的数量成正比。 另外，PTE通常保存在非分页内存中（对于内存pipe理员来说非常重要，所以应该总是驻留在内存中）。 这也解释了非分页池使用量的增加。
关于这个的一些链接：
http://www.dabcc.com/article.aspx?id=10571
http://blogs.msdn.com/b/david.wang/archive/2006/02/14/more-on-virtual-memory-memory-fragmentation-and-leaks-and-wow64.aspx
这些对于理解可能发生的事情也非常有帮助：
http://blogs.technet.com/b/markrussinovich/archive/2008/07/21/3092070.aspx
http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx
http://blogs.technet.com/b/markrussinovich/archive/2009/03/26/3211216.aspx
不幸的是，关于这一点你可以做的不多。 这个页面是特定于Exchange的，但也许它可以给你一些提示：
http://support.microsoft.com/kb/325044
这是一种问题，没有应用程序重新启动可以修复; 只有完整的服务器重新启动才能清除虚拟内存碎片。
使用x64系统可以在这里帮助，因为虚拟地址空间相当大; 但它不会修复碎片问题，所以也不会修复增加的PTE使用。