我们在 HAProxy 后面的 3 台服务器上运行 Asp.Net WebApi。HAProxy 只是在这 3 个实例之间随机分配请求。
这些实例连接到 mongodb、redis 和一些 windows 服务。
通常，w3wp.exe 在每个 api 服务器上使用大约 %30 cpu。
有时（一小时内几次）其中一个 api 服务器决定使用大量 cpu。与此行为相关的是，我们开始看到响应时间增加。这个数字一直在增加，直到 HAProxy 看到 10000 毫秒的响应时间并决定将请求路由到其他两个服务器。所有这些都发生在 10-20 秒内。一段时间后，该服务器恢复正常状态并再次开始接收请求。几分钟后，另一台服务器执行完全相同的操作。这种情况一直在继续。
我们正在使用 New Relic，但由于该应用程序是 WebApi 应用程序，因此我们没有得到任何有用的信息。我们监控所有服务器（redis、mongo 和 windows 服务）的 CPU 使用情况、内存使用情况、网络流量和 I/O，但在上述中断期间我们没有看到任何显着负载。
我们如何检测此应用程序行为背后的原因？
一个不错的选择是使用 Process Explorer 之类的东西进行小型转储，然后使用 WinDBG 或其他方式对其进行检查，以查看线程在做什么等等。我有一篇关于如何在这里做的很好的博客文章：
正如 DavidH 所说，获取内存转储是非常重要的一步。如果你愿意，我可以提供帮助来阅读转储。
另一个有用的也是免费的 CPU Analyzer：http: //samsaffron.com/archive/2009/11/11/Diagnosing+runaway+CPU+in+a+Net+production+application
另一种选择是使用PerfView。
另一种选择是使用 JetBrains dotTrace 并附加到 w3wp.exe 进程。
.NET 和 Java EE 之间共享的一件事是垃圾收集器。因此，如果您的应用程序使用大量内存，那么高 CPU 的时期可能是垃圾收集器的到来。我遇到了 .NET 3.5 IIS 7 运行的应用程序的问题，该应用程序始终使用每个进程超过 1 GB 的内存。垃圾收集器在为您的应用程序恢复内存时基本上会停止一切。您可以调整垃圾收集器，甚至在有意义时从您的代码中调用它。您可以使用很多小策略。如果你正在做很多很多字符串的事情，GC 会出现另一个问题。例如，您正在解析来自 Restful Web 服务的字符串。这会导致大量内存碎片，并可能导致 GC 花费更多时间和 CPU 来恢复内存。
如果这确实是正在发生的事情，很容易看到这种情况发生。您可以使用任务管理器查看进程的内存使用情况和 CPU。查看 CPU 上升时和再次下降后使用的内存。