我有一个64位的.NET控制台应用程序，基本上从MSMQ读取消息，然后通过.NET SqlClient与SQL服务器通信来处理它们。大多数时候它工作正常，但是时不时地进入一种状态，即使是最简单的操作，例如构建SqlCommand参数数组，运行异常缓慢。在最糟糕的情况下，应用程序一次完成30分钟没有任何操作（没有写入日志，并且在详细模式开启时非常繁琐），然后将再次开始写入，没有指示导致延迟的原因。这严重影响了我们产品的可用性。
我花了最后几个小时查看每个单独的性能计数器等等，而且所有内容都指向过多的页面读取 - 由于这一点，它在磁盘I / O上最大化，我可以看到我的进程不断地从页面文件中大量读取.sys等等。但我不明白为什么，因为应用程序的总内存使用量远低于可用的RAM：工作集是60M，总提交大小是300M（高，并匹配峰值工作集 - 不确定为什么会这样），但这是花生与可用的12千兆RAM相比，其中很少使用。
我已阅读每篇关于监控应用程序性能等的MS文档，但所有内容都指向“我的应用程序需要更多内存”。好的...那么它如何给它带来更多的记忆 - 没有别的东西在使用它！现在有一个单独的问题，考虑到应用程序的功能，它实际上不需要那么多的内存，但是为了降低内存所需的努力可能不值得花费更多的硬件。
还有一点需要注意：如果我启动同一个应用程序的第二个实例，它似乎运行正常。所以这显然不是系统范围内的问题。
我在stackoverflow上看过一些类似的帖子，但还没有特别有用的答案......希望比以前的海报更幸运。
答案 0 :(得分：0)
任务管理器中的页面错误意味着磁盘上页面文件的命中率，默认为已安装的RAM量的1.5倍。它不一定是坏的，它只是告诉你数据的位置。您可以关闭分页文件以查看此号码保持为0。
您是否查看过您所依赖产品的性能和计数器，例如SQL Server或MSMQ？你试过memtest86来测试你的ram吗？
答案 1 :(得分：0)
我遇到了同样的问题。根据我的经验，你有强烈的“永远在线”的应用;它们应该放在Windows服务而不是控制台应用程序中。
据说这可能是垃圾收集问题。
将此添加到您的配置文件中：
<runtime>
<gcServer enabled="True"/>
</runtime>
您需要将其放在配置节点下。
根据我的经验，这将导致应用程序拥有更少的PageFaults和更大的工作集。
没有银弹。如果没有代码，就无法知道代码是否泄漏了内存;这可能是过度分页的另一个原因。