在 IIS6 上运行的 ASP.NET Web 应用程序会定期将 CPU 提高到 100%。在这些情节中，几乎所有 CPU 使用都是由 W3WP 负责的。CPU 在几分钟到一个多小时内保持 100%。
这是在登台服务器上，此时该站点仅从测试人员那里获得非常少的流量。
我们已经在服务器上运行了 ANTS 分析器，但它一直没有启发性。
我们从哪里开始找出导致这些事件的原因以及在这段时间里让 CPU 忙碌的代码是什么？
问问题
132412 次
9 回答
38
- 标准 Windows 性能计数器（查找其他相关活动，例如许多 GET 请求、过多的网络或磁盘 I/O 等）；您可以从代码和 perfmon 中读取它们（例如，如果 CPU 使用率超过阈值，则触发数据收集）
- 自定义性能计数器（特别是针对执行时间不确定的开箱请求和其他调用的时间）
- 负载测试，使用 Visual Studio Team Test 或 WCAT 等工具
- 如果您可以在 IIS 7 上进行测试或升级到 IIS 7，则可以配置 Failed Request Tracing 以在请求花费更多时间时生成跟踪
- 使用 logparser 查看 CPU 峰值时到达的请求
- 代码审查/演练（特别是寻找可能无法正确终止的循环，例如是否发生错误，以及锁定和潜在的线程问题，例如使用静态）
- CPU 和内存分析（在生产系统上可能很困难）
- 进程浏览器
- Windows 资源监视器
- 详细的错误记录
- 自定义跟踪日志记录，包括执行时间详细信息（可能是有条件的，基于 CPU 使用性能计数器）
- AppPool 回收时是否会发生错误？如果是这样，它可能是一个线索。
于 2010-01-13T09:59:25.207 回答
12
这不是一个很好的答案，但您可能需要回到老学校并捕获 IIS 进程的图像快照并对其进行调试。您可能还想查看Tess Ferrandez的博客 - 她是一位出色的微软升级工程师，她的博客专注于调试 windows ASP.NET，但该博客通常与 windows 调试相关。如果您选择 ASP.NET 标记（我已链接到该标记），那么您将看到几个相似的项目。
于 2010-01-12T21:52:22.720 回答
4
如果您的 CPU 达到 100% 并保持在那里，那么您很可能遇到死锁情况或无限循环。探查器似乎是寻找无限循环的好选择。然而，死锁更难追踪。
于 2010-01-12T21:50:24.300 回答
4
Process Explorer是一款出色的故障排除工具。您可以尝试使用它来查找CPU使用率高的问题。它让您深入了解应用程序的工作方式。
您还可以尝试Procdump转储进程并分析 CPU 上实际发生的情况。
于 2010-01-13T00:35:38.870 回答
1
另外，请查看您的性能计数器。他们可以告诉你很多 CPU 时间都花在了哪里。以下是最常用计数器的链接：
于 2010-01-12T22:13:54.877 回答
0
我们在将大量数据转储到输出的递归查询中遇到了这个问题 - 您是否仔细检查了所有内容是否退出并且不存在无限循环？
可能会尝试用一个页面来缩小范围 - 我们发现 ANTS 在同样的情况下也没有太大帮助 - 我们最终做的是运行网站点击页面查看 CPU - 点击下一页查看 CPU - 非常有条不紊并且耗时，但如果您无法通过一些代码跟踪找到它，您可能会不走运 -
我们能够使用 IIS 日志文件将其跟踪到一组可疑页面 -
希望有帮助！
于 2010-01-12T21:46:07.533 回答
0
这充其量只是猜测，但也许您的开发团队正在以调试模式而不是发布模式构建和部署应用程序。这将导致 .pdb 文件的出现。这意味着您的应用程序将在系统执行期间占用额外的资源来收集系统状态和调试信息，从而导致更多的处理器利用率。
因此，确保它们在发布模式下构建和部署就足够简单了。
于 2016-12-30T19:09:27.337 回答
-1
这是一个非常古老的帖子，我知道，但这也是一个常见问题。所有建议的方法都非常好，但它们总是指向一个进程，而且我们很可能已经知道我们的网站正在出现问题，但我们只想知道哪个特定页面在处理上花费了太多时间。在我看来，最精确和最简单的工具是 IIS 本身。
- 只需在 IIS 的左窗格中单击您的服务器。
- 单击主窗格中的“工作进程”。您已经看到哪个应用程序池占用了过多的 CPU。
- 双击此行（最终通过单击“显示全部”刷新）以查看此池中哪些页面消耗过多 CPU 时间（“已用时间”列）
于 2017-09-12T14:44:26.373 回答
-2
如果您确定加载需要时间的页面，请使用 SharePoint 的开发人员仪表板查看哪个组件需要时间。
于 2012-10-26T14:00:19.950 回答