Sharepoint W3WP.EXE 进程消耗 100% CPU - 纠正措施？
我们有一台 Windows Server 2003 Web 服务器，该服务器上运行大约 5-6 个顶级 Sharepoint 站点，每个站点都有不同的应用程序池。
有一个 W3WP 进程在一天的大部分时间里保持 100% 的状态（昨天和今天发生），并且它连接（通过在命令行执行“Cscript iisapp.vbs”并匹配 ProcessID 找到）到特定的 Sharepoint 站点...这几乎无法使用。
我可以采取什么样的纠正措施？这些是我的以下想法
1) 停止并重新启动 IIS 中的网站 - 由于某种原因，这并没有停止有问题的 W3WP 进程？？？有什么想法为什么不呢？
2) 停止并重新启动关联的应用程序池。
3）回收关联的应用程序池。
这些听起来像是正确的想法吗？如果没有，有哪些好的事情可以尝试？我无法执行 iisreset，因为我不想更改其他使用频率更高的 Sharepoint 站点的服务。
如果我确实需要做一些诊断工作，请为我指明正确的方向。我不是 Sharepoint 管理员（他不在城里，所以我正在填补，尽管我只是一名开发人员），但我会尽力而为。
如果您需要任何信息，请告诉我，我会查找（尽管速度很慢，因为该过程正在固定整个机器）。
We have a Windows Server 2003 web server, and on that server runs about 5-6 top level Sharepoint sites, with a different application pool for each one.
There is one W3WP process that keeps pegging 100% for most of the day (happened yesterday and today) and it's connected (found by doing "Cscript iisapp.vbs" at the command line and matching ProcessID) to a particular Sharepoint site...which is nearly unusable.
What kind of corrective action can I take? These are the following ideas I had
1) Stopping and restarting the Web Site in IIS - For some reason this didn't stop the offending W3WP process??? Any ideas why not?
2) Stopping and restarting the associated Application Pool.
3) Recycling the associated Application Pool.
Any of those sound like the right idea? If not what are some good things to try? I can't do an iisreset since I don't want to alter service to the other, much more heavily used, Sharepoint sites.
If I truly NEED to do some diagnostic work please point me in the right direction. I'm not the Sharepoint admin guy (he's out of town so I'm filling in even though I'm just a developer) but I'll do my best.
If you need any information just let me know and I'll look it up (slowly though, as that one process is pegging the entire machine).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这不是您需要的 IISReset。你有一段代码在你的记忆中疯狂运行。很可能实际上不是 CPU 问题，而是分页问题。我已经遇到过几次这种情况，内存中的数据结构变得太大而无法有效地分页输入/输出，最终尝试分页数据就开始消耗所有内容。我建议的步骤是：
1) 获取 IIS 调试诊断 工具。并了解如何使用它们。
2) 如果可能，将会话状态从 InProc 删除到状态服务器或 SQL 服务器（因为这需要序列化进入会话的所有类，这可能是不可能的）。这将有助于缓解一些与进程相关的内存问题。
3) 进入您的应用程序池并向上调整工作进程数。删除快速失败保护（这将允许站点继续提供页面，即使发生快速灾难性错误）。
IIS 调试诊断将记录大量数据，但您可以指定特定的“捕获”警报来检测挂起、CPU 使用率过高等。它将捕获大量数据，因此在尝试查看日志时要做好长时间等待的准备。
It's not an IISReset that you need. You have a piece of code that is running amok with your memory. Most likely it's not actually a CPU problem but a paging problem. I've encountered this a few times with data structures in memory that grow too large to page in/out effectively and eventually the attempt to page data just begins consuming everything. The steps I would recommend are:
1) Go get the IIS Debug Diagnostics tools. And learn how to use them.
2) If possible, remove the session state from InProc to a state server or a sql server (since this requires serialization of all classes that go into session this may not be possible). This will help alleviate some process related memory issues.
3) Go to your application pool and adjust the number of worker processes upward. Remove Rapid fail protection (this will allow the site to continue serving pages even if rapid catastrophic errors occur).
The IIS debug diagnostics will record a LOT of data, but you can specify specific "catch" alerts that will detect hangs, excessive cpu usage etc. It will capture gigs of data, so be ready for a long wait when attempting to view the logs.
事实证明，有人试图安装一些失控的功能。
因此，他编写了一个 stsadm 脚本来卸载那些
处理器仍然挂着的功能。
我重新启动了该 IIS 进程的 IIS 应用程序池，但没有修复它。
然后我为该站点重新启动了 IIS，这解决了处理器问题。
Turns out someone tried to install some features that went haywire.
So he wrote a stsadm script to uninstall those features
Processor was still pegging.
I restarted the IIS Application Pool for that IIS process, didn't fix it.
So then I restarted IIS for that site and that resolved the processor issue.