为什么我的 .NET 应用程序会产生如此多的页面错误？答案

【问题标题】：Why is my .NET application generating so many page faults?为什么我的 .NET 应用程序会产生如此多的页面错误？
【发布时间】：2013-01-07 18:02:07
【问题描述】：

我有一个 64 位 .NET 控制台应用程序，它基本上从 MSMQ 读取消息，然后通过 .NET SqlClient 与 SQL 服务器通信来处理它们。大多数时候它工作正常，但时不时地让自己进入一个状态，即使是最简单的操作，例如构建 SqlCommand 参数数组，都运行异常缓慢。在最坏的情况下，应用程序一次 30 分钟什么都不做（什么都没有写入日志，并且在详细模式打开时非常健谈），然后将再次开始写入，没有任何迹象表明导致延迟的原因。这严重影响了我们产品的可用性。

过去几个小时我一直在查看每一个性能计数器等，一切都表明页面读取过多 - 因此磁盘 I/O 已达到最大值，我可以看到我的进程不断从页面文件中大量读取.sys 等等，但我不知道为什么，因为应用程序的总内存使用量远低于可用 RAM：工作集为 60M，总提交大小为 300M（高，与峰值工作集匹配 - 不确定为什么会这样），但与可用的 12 Gig RAM 相比，这简直是小菜一碟。

我已经阅读了关于监控应用程序性能等的每一个 MS 文档，但所有内容都指向“我的应用程序需要更多内存”。好的......那么它如何给它更多的内存 - 没有其他东西在使用它！现在有一个单独的问题，考虑到应用程序的功能，它确实不应该需要那么多内存，但为了降低内存而付出的努力可能不值得更多硬件的成本。

还有一点需要注意：如果我启动同一个应用程序的第二个实例，它似乎运行良好。所以这显然不是系统范围的问题。

我在 stackoverflow 上看到了一些类似的帖子，但还没有特别有用的答案……希望比以前的海报更幸运。

【问题讨论】：

您是否尝试过在这些超慢期间分析程序并查看它花费最多时间的方法？ Visual Studio 有一个非常好的分析器
系统中还发生了什么？您是否有其他 CPU 密集型进程正在进行？ SQL Server 数据库在哪里运行？此控制台应用程序每分钟处理多少条消息？您的环境中可能有很多问题导致问题...使用 Visual Studio 调试器并在那些缓慢的时间附加到进程将是一个好的开始。代码是否足够小，您可以提供一些核心逻辑示例，例如 Pastie？
是的，我什么都试过了——它没有做任何它一直没有做的事情。系统上没有其他任何东西在使用任何 CPU 或内存。 Sql server 在别处。我想知道高页面错误是否必然相关，因为我只是查看了该进程的所有磁盘 i/o，它实际上对 MSMQ 存储区域进行了更多写入（以及为什么要写入- 这个过程甚至不生成消息，只删除它们？）而不是从 pagefile.sys 读取
队列的负载是多少？应用程序是否始终排在队列前面，或者是否有积压？
有一个巨大的积压 - 至少 50000 条消息。当它变得太大时，客户端被写入限制，但瓶颈不应该发生。这可能是相关的：support.microsoft.com/kb/897326，但它并没有真正解释为什么其他简单的非 MSMQ 相关操作开始运行如此缓慢，也没有解释为什么应用程序的第二个实例能够正常运行。

标签： .net performance memory paging

【解决方案1】：

任务管理器中的页面错误意味着对磁盘上页面文件的点击，默认为您安装的 RAM 数量的 1.5 倍。这不一定是坏事，它只是告诉你数据在哪里。您可以关闭分页文件，让这个数字保持为 0。

您是否查看过您所依赖的产品（如 SQL Server 或 MSMQ）的性能和计数器？您是否尝试过 memtest86 来测试您的内存？

【讨论】：

我现在似乎再次处于这种状态，并且使用最新的 procmon，它正在执行的唯一操作（并且仅针对页面文件和 .NET 程序集）是 ReadFile。没有其他任何 Win32 调用，现在已经有 30 多分钟了。奇怪。

【解决方案2】：

我遇到了同样的问题。根据我的经验，当您有“始终在线”的密集应用程序时；它们应该放在 Windows 服务而不是控制台应用程序中。

话虽如此，这可能是垃圾收集的问题。

将此添加到您的配置文件中：

<runtime>
  <gcServer enabled="True"/>
</runtime>

你需要把它放在配置节点下。

根据我的经验，这将导致应用程序的 PageFaults 更少，工作集更大。

没有灵丹妙药。如果没有代码，就无法知道您的代码是否正在泄漏内存；这可能是过度分页的另一个原因。

【讨论】：