页表快速增长

Question

不久前我发现了一个非常有趣的工具RamMap。我在几台运行我们 x32 软件的服务器上发现 PAGE TABLE 增长非常快——每天 1.2 GB（总共 10 GB）。此外，NONPAGED POOL 每天增长 300MB。

1. 任何人都可以解释通常的原因吗？
2. 如何从代码中获取 PAGE TABLE 的大小（例如 API 函数或 WMI 类）？
3. 可以减少、清除或......释放RAM吗？

我们有称为1C（俄罗斯商业导向平台）的编程和执行平台。一个进程就像其他进程的管理器，它们按计划启动并由规则终止，并执行不同类型的数据处理，包括使用 COM 与另一个数据库交换。换句话说，我不知道平台级别发生了什么（它对我们隐藏）。我们从平台开发人员那里得到了一些不快 (=)) 的支持——他们仍然没有回答我们关于这个问题的问题。

我们有不同的操作系统配置（2003 和 2008 服务器、x32 和 x64）。页表随处增长。增长速度与同时运行的进程数成正比（在主服务器 30-40 上）。当 PAGE TABLE 达到 RAM 的 50-70% 时，服务器开始以不同的方式出现故障。

Answer 1

看起来像是虚拟内存碎片问题；内存被连续分配和释放，并且每次创建新的页表条目 (PTE) 以跟踪内存页面；您断言正在创建和终止大量进程，并且此页表的增加与正在运行的进程数量成正比，实际上指向这个方向。此外，PTE 通常保存在非分页内存中（它们对内存管理器至关重要，因此应始终驻留在内存中）；这也解释了非分页池使用量的增加。

关于这个的一些链接：

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

这是一种应用重启无法解决的问题；只有完全重新启动服务器才能清除虚拟内存碎片。

使用64位系统可以帮助在这里，因为虚拟地址空间是相当大; 但它不会解决碎片问题，因此它也不会解决增加的 PTE 使用。