W3WP.EXE 使用 100% CPU - 从哪里开始？
在 IIS6 上运行的 ASP.NET Web 应用程序会定期使 CPU 达到 100%。在这些事件中，几乎所有的 CPU 使用情况都是由 W3WP 负责的。 CPU 在几分钟到一个多小时的任何时间都保持在 100%。
这是在临时服务器上，此时该站点仅从测试人员那里获得了很少的流量。
我们已经在服务器上运行了 ANTS profiler，但效果并不理想。
我们可以从哪里开始找出导致这些事件的原因以及哪些代码在这段时间内使 CPU 保持忙碌？
An ASP.NET web app running on IIS6 periodically shoots the CPU up to 100%. It's the W3WP that's responsible for nearly all CPU usage during these episodes. The CPU stays pinned at 100% anywhere from a few minutes to over an hour.
This is on a staging server and the site is only getting very light traffic from testers at this point.
We've running ANTS profiler on the server, but it's been unenlightening.
Where can we start finding out what's causing these episodes and what code is keeping the CPU busy during all that time?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
这并不是一个很好的答案，但您可能需要采用传统方式捕获 IIS 进程的映像快照并对其进行调试。您可能还想查看 Tess Ferrandez 的博客 - 她是一位出色的 Microsoft 升级工程师，她的博客重点关注调试 Windows ASP.NET，但该博客总体上与 Windows 调试相关。如果您选择 ASP.NET 标记（这就是我链接到的标记），那么您将看到几个类似的项目。
It's not much of an answer, but you might need to go old school and capture an image snapshot of the IIS process and debug it. You might also want to check out Tess Ferrandez's blog - she is a kick a** microsoft escalation engineer and her blog focuses on debugging windows ASP.NET, but the blog is relevant to windows debugging in general. If you select the ASP.NET tag (which is what I've linked to) then you'll see several items that are similar.
如果您的 CPU 峰值达到 100% 并保持在该水平，则很可能出现死锁情况或无限循环。分析器似乎是查找无限循环的不错选择。然而，追踪死锁要困难得多。
If your CPU is spiking to 100% and staying there, it's quite likely that you either have a deadlock scenario or an infinite loop. A profiler seems like a good choice for finding an infinite loop. Deadlocks are much more difficult to track down, however.
ProcessExplorer 是一个出色的故障排除工具。您可以尝试查找CPU使用率高的问题。它可以让您深入了解应用程序的工作方式。
您还可以尝试 Procdump 转储进程并分析到底发生了什么在CPU上。
Process Explorer is an excellent tool for troubleshooting. You can try it for finding the problem of high CPU usage. It gives you an insight into the way your application works.
You can also try Procdump to dump the process and analyze what really happened on the CPU.
另外，请查看您的性能计数器。他们可以告诉您大量 cpu 时间都花在哪里了。以下是最常用计数器的链接：
Also, look at your perfmon counters. They can tell you where a lot of that cpu time is being spent. Here's a link to the most common counters to use:
我们在一个递归查询中遇到了这个问题，该查询将大量数据转储到输出中 - 您是否仔细检查了所有内容是否退出并且不存在无限循环？
可能会尝试用单个页面缩小范围 - 我们发现 ANTS 在同样的情况下也没有多大帮助 - 我们最终做的是运行该网站，点击一个页面，观察 CPU - 点击下一个页面，观察 CPU - 非常有条理并且耗时，但如果您无法通过一些代码跟踪找到它，您可能会运气不佳 -
我们能够使用 IIS 日志文件将其跟踪到一组可疑的页面 -
希望有所帮助！
We had this on a recursive query that was dumping tons of data to the output - have you double checked everything does exit and no infinite loops exist?
Might try to narrow it down with a single page - we found ANTS to not be much help in that same case either - what we ended up doing was running the site hit a page watch the CPU - hit the next page watch CPU - very methodical and time consuming but if you cant find it with some code tracing you might be out of luck -
We were able to use IIS log files to track it to a set of pages that were suspect -
Hope that helps !
这充其量只是猜测，但也许您的开发团队正在调试模式而不是发布模式下构建和部署应用程序。这将导致.pdb 文件的出现。这意味着您的应用程序将在系统执行期间占用额外的资源来收集系统状态和调试信息，从而导致更多的处理器利用率。
因此，确保它们在发布模式下构建和部署就足够简单了。
This is a guess at best, but perhaps your development team is building and deploying the application in debug mode, in stead of release mode. This will cause the occurrence of .pdb files. The implication of this is that your application will take up additional resources to collect system state and debugging information during the execution of your system, causing more processor utilization.
So, it would be simple enough to ensure that they are building and deploying in release mode.
我知道这是一篇很老的帖子，但这也是一个常见问题。所有建议的方法都非常好，但它们总是指向一个进程，并且很可能我们已经知道我们的网站出现了问题，但我们只想知道哪个特定页面在处理上花费了太多时间。
我认为最精确和简单的工具是 IIS 本身。
列）在此池中
This is a very old post, I know, but this is also a common problem. All of the suggested methods are very nice but they will always point to a process, and there are many chances that we already know that our site is making problems, but we just want to know what specific page is spending too much time in processing.
The most precise and simple tool in my opinion is IIS itself.
column) in this pool
如果您发现加载时间较长的页面，请使用 SharePoint 的 开发者仪表板来查看哪个组件需要时间。
If you identify a page that takes time to load, use SharePoint's Developer Dashboard to see which component takes time.