工作进程占用高 CPU%
我的所有网站都托管在 IIS 中，并配置了一个应用程序池。该应用程序池由 10 个正在运行的网站组成。
直到今天它都工作正常，但突然我发现 CPU 使用率突然上升和下降。我无法找出问题所在。
无论如何，有没有办法检查应用程序池中哪个网站负载最多？
All of my websites are hosted in IIS and configured with one application pool. This application pool consists 10 websites running.
It is working fine till today, but all of sudden I am observing that there is sudden up and down % in CPU usage. I am unable to trace out the problem.
Is there anyway to check which website is taking much load among all in the application pool?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
性能计数器、任务管理器和本机代码分析工具只能说明部分情况。为了更深入地了解 ASP.NET 应用程序内部发生的情况，您需要使用 WinDBG、SOS 和 ADPlus。
Tess Ferrandez 有一系列精彩的文章，讲述了追踪什么是归咎于此：
这是一个真实的示例：
您可能希望将您的网站分成单独的应用程序池，以便您可以识别并隔离导致 CPU 过高的站点（但看起来您已经有了嫌疑，所以我会隔离该站点）。从那时起你就可以按照Tess的建议和指导来追查原因。
您还应该查看日志，看看是否遇到意外的流量高峰或增加。也许有一个行为不良的搜索引擎站点索引器钉住了该站点。如果是这种情况，那么您可能需要（如果您尚未这样做）创建一个
robots.txt以防止抓取工具对网站中不需要索引的部分进行索引。最重要的是，如果某些爬虫过于积极，那么就禁止它们。也许可以考虑为谷歌提供一个站点地图来驯服和调整其活动。Performance counters, task manager and native code analysis tools only tell part of the story. To gain a deeper understanding of what is happening inside your ASP.NET application you need to use WinDBG, SOS and ADPlus.
Tess Ferrandez has a great series of articles on tracking down what is to blame here:
This is a real world example:
You will probably want to separate your sites into individual application pools so you can identify and isolate the site that is causing the high CPU (but it already looks like you have a suspect so I'd isolate that one). From then you can follow Tess's advice and guidance to track down the cause.
You should also take a look at the logs to see if you're experiencing an unexpected spike or increase in traffic. Perhaps there's a badly behaved search engine site indexer nailing the site. If that's the case then maybe you need to (if you haven't already done so) create a
robots.txtto prevent crawlers from indexing parts of the site that don't need to be indexed. On top of that if certain crawlers are being overly promiscious then just ban them. Perhaps consider a sitemap for google to tame and tune its activities.如果您的服务器已达到最大容量，您将看到 CPU 不稳定地上升和下降，因为 GC 将开始尝试恢复资源（缓存等），这反过来又会导致您的站点工作更加困难。这是一个无限循环。
您是否一直在监控性能计数器？您知道您的站点的正常容量是多少吗？如果您无法回答这些问题，我建议您尽快收集一些性能数据。
我的经验法则是始终先进行测量，然后进行必要的更改。
大多数时候，性能瓶颈并不在您想象的地方。
If your server has reached it's max capacity, you will see CPU go up and down erratically because the GC will start trying to recover resources(cache..etc), which in turn causes your sites to work even harder. It's an endless cycle.
Have you been monitoring your performance counters? Do you have any idea what normal capacity is for your site? If you cannot answer these questions, I suggest you gather some perf numbers as soon as possible.
My rule of thumb is to always measure first, then make necessary changes.
Most of the time performance bottlenecks aren't where you think they would be.
实际上没有性能计数器的方法可以判断，因为 CPU 计数器处于进程级别。最好的选择是与事件日志中的其他事件和 .NET/ASP.NET 计数器进行时间关联，以进行垃圾收集、请求等。
如果您真的想变得更硬核，您可以使用 SysInternals 工具集来拍摄快照随着时间的推移您的应用程序池，然后进行事后分析以找出高峰发生时执行了哪些代码。以下是 Mark Russinovich 博客中的相关示例 - http:// /blogs.technet.com/b/markrussinovich/archive/2008/04/07/3031251.aspx。
There is really no performance counter way to tell, because the CPU counters are at the process level. Your best bet would be to do a time corelation with other events in the event log and .NET/ASP.NET counters for garbage collection, requests etc.
If you really want to go hardcore, you could use the SysInternals toolset to take snapshots of your app pool over time and then do a post-analysis to figure out what code was executed when the spike happened. Here is a related example from Mark Russinovich's blog - http://blogs.technet.com/b/markrussinovich/archive/2008/04/07/3031251.aspx.