在IIS6上运行的ASP.NET Web应用程序会定期向CPU发送高达100%的CPU。在这些剧集中,W3WP几乎负责所有CPU的使用。 CPU在几分钟到一个多小时的任何地方都保持100%固定。
这是在登台服务器上,此时该站点只能从测试人员那里获得非常轻的流量。
我们在服务器上运行ANTS探查器,但它一直没有启发。
我们在哪里可以开始找出造成这些剧集的原因以及在这段时间内CPU保持繁忙的代码?
答案 0 :(得分:36)
答案 1 :(得分:12)
这不是一个很好的答案,但您可能需要上学并捕获IIS进程的映像快照并对其进行调试。您可能还想查看Tess Ferrandez的博客 - 她是一名*微软升级工程师,她的博客专注于调试Windows ASP.NET,但该博客通常与Windows调试相关。如果您选择ASP.NET标记(这是我链接到的),那么您将看到几个相似的项目。
答案 2 :(得分:4)
如果您的CPU达到100%并且停留在那里,那么您很可能遇到死锁情况或无限循环。分析器似乎是寻找无限循环的好选择。然而,死锁更难以追查。
答案 3 :(得分:4)
Process Explorer是一款出色的故障排除工具。您可以尝试查找高CPU使用率的问题。它可以让您深入了解应用程序的工作方式。
您也可以尝试Procdump转储进程并分析CPU上发生的事情。
答案 4 :(得分:1)
另外,看看你的perfmon专柜。他们可以告诉你在哪里花费了大量的cpu时间。这是一个指向最常用的计数器的链接:
答案 5 :(得分:0)
我们有一个递归查询,它将大量数据转储到输出中 - 你是否仔细检查过一切都退出并且没有无限循环?
可能会尝试用一个页面来缩小它 - 我们发现ANTS在同样的情况下也没有多大帮助 - 我们最终做的是运行网站点击一个页面观看CPU - 点击下一页观看CPU - 非常有条理和耗时,但如果你找不到一些代码跟踪,你可能会失败 -
我们能够使用IIS日志文件将其跟踪到一组可疑的页面 -
希望有所帮助!
答案 6 :(得分:0)
这是最好的猜测,但也许您的开发团队正在以调试模式构建和部署应用程序,而不是发布模式。这将导致.pdb文件的出现。这意味着您的应用程序将占用额外的资源来收集系统执行期间的系统状态和调试信息,从而提高处理器利用率。
因此,确保他们在发布模式下构建和部署非常简单。
答案 7 :(得分:-1)
这是一篇非常古老的帖子,我知道,但这也是一个常见的问题。所有建议的方法都非常好,但它们总是指向一个过程,并且我们很多机会已经知道我们的网站存在问题,但我们只想知道哪些特定页面在处理上花费了太多时间。 我认为最精确和最简单的工具是IIS本身。
答案 8 :(得分:-2)
如果您确定需要时间加载的页面,请使用SharePoint的Developer Dashboard查看哪个组件需要时间。