W3WP.EXE 使用 100% CPU - 从哪里开始？答案

【问题标题】：W3WP.EXE using 100% CPU - where to start?W3WP.EXE 使用 100% CPU - 从哪里开始？
【发布时间】：2011-01-04 09:20:36
【问题描述】：

在 IIS6 上运行的 ASP.NET Web 应用程序会定期将 CPU 提高到 100%。在这些情节中，几乎所有 CPU 使用都是由 W3WP 负责的。 CPU 在几分钟到一个多小时内保持 100%。

这是在登台服务器上，此时该站点仅从测试人员那里获得非常少的流量。

我们已经在服务器上运行了 ANTS 分析器，但它一直没有启发性。

我们可以从哪里开始找出导致这些事件的原因以及在这段时间里 CPU 一直处于忙碌状态的代码是什么？

【问题讨论】：

您是否以某种方式在代码中记录异常？调用类似“Logger.Log(Exception)”的东西？

标签： asp.net profiling w3wp red-gate-ants

【解决方案1】：

我们在递归查询中遇到了这个问题，该查询将大量数据转储到输出 - 您是否仔细检查了所有内容是否退出并且不存在无限循环？

可能会尝试用一个页面来缩小范围 - 我们发现 ANTS 在同样的情况下也没有太大帮助 - 我们最终做的是运行网站点击页面查看 CPU - 点击下一页查看 CPU - 非常有条理且耗时，但如果您无法通过一些代码跟踪找到它，您可能会不走运 -

我们能够使用 IIS 日志文件将其跟踪到一组可疑页面 -

希望有帮助！

【讨论】：

【解决方案2】：

如果您的 CPU 达到 100% 并保持在该状态，则很可能出现死锁情况或无限循环。探查器似乎是寻找无限循环的好选择。然而，死锁更难追踪。

【讨论】：

使用 dotTrace 分析器并通过“所有线程”选择“调用树”，这应该显示大多数 CPU 使用的方法被分组到 1 个调用堆栈中。追踪以查看确切的位置。

【解决方案3】：

这不是一个很好的答案，但您可能需要老去，捕获 IIS 进程的图像快照并对其进行调试。您可能还想查看Tess Ferrandez 的博客——她是一位出色的微软升级工程师，她的博客专注于调试 windows ASP.NET，但该博客通常与 windows 调试相关。如果您选择 ASP.NET 标记（我已链接到该标记），那么您将看到几个相似的项目。

【讨论】：

【解决方案4】：

另外，请查看您的性能计数器。他们可以告诉你很多 CPU 时间都花在了哪里。以下是最常用计数器的链接：

【讨论】：

【解决方案5】：

Process Explorer 是一款出色的故障排除工具。您可以尝试使用它来查找 CPU 使用率高的问题。它让您深入了解应用程序的工作方式。

你也可以尝试Procdump转储进程并分析CPU上到底发生了什么。

【讨论】：

以编程方式使用 Process Explorer ?

【解决方案6】：

标准 Windows 性能计数器（查找其他相关活动，例如许多 GET 请求、过多的网络或磁盘 I/O 等）；您可以从代码和 perfmon 中读取它们（例如，如果 CPU 使用率超过阈值，则触发数据收集）
自定义性能计数器（尤其是针对执行时间不确定的开箱即用请求和其他调用的时间）
负载测试，使用 Visual Studio Team Test 或 WCAT 等工具
如果您可以在 IIS 7 上进行测试或升级到 IIS 7，则可以配置失败请求跟踪以在请求花费一定时间时生成跟踪
使用 logparser 查看 CPU 峰值时到达的请求
代码审查/演练（特别是寻找可能无法正确终止的循环，例如发生错误，以及锁定和潜在的线程问题，例如使用静态变量）
CPU 和内存分析（在生产系统上可能很困难）
进程浏览器
Windows 资源监视器
详细的错误记录
自定义跟踪日志记录，包括执行时间详细信息（可能是有条件的，基于 CPU 使用性能计数器）
AppPool 回收时是否发生错误？如果是这样，它可能是一个线索。

【讨论】：

我将添加最终将我们带到问题根源的记录：SQL Profiler。我们有一个复杂的 LINQ to SQL 查询，其中包含对内存中对象的引用，因此它无法将整个查询转换到内存中，而是触发了数以千计的小 SQL 查询来执行连接。
源代码示例真实世界关于 1) 性能计数器 , 2) 自定义性能计数器, 5) logparser, 7) CPU 和内存分析, 10) 详细的错误记录，11) 自定义跟踪记录 ?

【解决方案7】：

如果您确定加载需要时间的页面，请使用 SharePoint 的 Developer Dashboard 查看哪个组件需要时间。

【讨论】：

【解决方案8】：

这充其量只是猜测，但也许您的开发团队正在以调试模式而不是发布模式构建和部署应用程序。这将导致 .pdb 文件的出现。这意味着您的应用程序将在系统执行期间占用额外的资源来收集系统状态和调试信息，从而导致更多的处理器利用率。

因此，确保它们在发布模式下构建和部署很简单。

【讨论】：

【解决方案9】：

这是一个很老的帖子，我知道，但这也是一个常见问题。所有建议的方法都非常好，但它们总是指向一个进程，而且我们很可能已经知道我们的网站正在出现问题，但我们只想知道哪个特定页面在处理上花费了太多时间。我认为最精确和最简单的工具是 IIS 本身。

只需在 IIS 的左窗格中单击您的服务器。
单击主窗格中的“工作进程”。您已经看到哪个应用程序池占用了过多的 CPU。
双击此行（最终通过单击“显示全部”刷新）以查看哪些页面消耗过多的 CPU 时间（“已用时间” 列）在这个池中

【讨论】：

如果我双击一个工作进程，什么也没有发生。为什么会这样？