4

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

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

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

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

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

4

2 回答 2

0

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

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

于 2013-04-19T21:44:02.923 回答
0

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

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

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

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

您需要将其放在配置节点下。

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

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

于 2016-10-20T12:29:02.743 回答