IIS 7 上的 WordPress php-cgi 占用 CPU

发布于 2025-01-05 03:45:11 字数 430 浏览 1 评论 0原文

在 IIS 7 (Windows Server 2008) 上使用 WP-SuperCache 运行 WordPress,按照 IIS.net 指南。

运行良好,但最近我们更改了某些文件夹的权限和管理员密码,并且出现了巨大的峰值PHP-cgi.exe 进程导致的 CPU 使用情况。

CPU 使用情况

让我相信它没有缓存,但是页面本身底部有“使用 WP-SuperCache 缓存”注释,并且缓存似乎工作正常。

这里还有什么问题?

Running WordPress on IIS 7 (Windows Server 2008) with WP-SuperCache as per IIS.net's guide.

Was running great but recently we changed the permissions on some folders and the administrator password and we're getting huge spikes in our CPU usage as a result of the PHP-cgi.exe processes.

cpu usage

php-cgi.exe processes

This leads me to believe it's not caching however the pages themselves have the "Cached with WP-SuperCache" comments at the bottom, and the caching seems to be working correctly.

What else could be the issue here?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

公布 2025-01-12 03:45:11

我想我可能已经找到了解决方案,或者至少找到了解决这个问题的方法,至少它似乎对我来说可靠。

尝试在 IIS 服务器 --> 下设置最大实例数设置FastCGI 设置,为 1。

在我看来,只有某些请求才会导致 php-cgi.exe 进程变得异常并占用 CPU,通常是在更新帖子时。在阅读有关此问题的其他帖子时,其中一篇提到了“最大实例数”设置,并将其设置为默认值 0 或自动。我想知道,当事情不正常时,这是否会产生良好的效果。我猜测(但这不完全是我的专业领域)如果某个请求导致进程锁定,那么 FastCGI 只是创建另一个请求,同时保留第一个请求。不知何故,似乎只有一个实例可以让 PHP 摆脱锁定状态,并且 cpu 保持在控制之下。

对于具有高级别请求的服务器,将 FastCGI 仅设置为单个实例可能并不理想,但它确实比我之前遇到的延迟要好。与 WP-SuperCache 和 WinCache 结合使用,现在一切似乎进展顺利。

I think I may have found a solution or at least a work round to this problem, at least it seems to be working for me reliably.

Try setting the Max Instances setting, under IIS Server --> FastCGI Settings, to 1.

It seemed to me that only certain requests were causing a php-cgi.exe process to go rogue and hog the cpu, usually when updating a post. When reading other posts on this issue one of them mentioned the Max Instances setting and that it is set to default at 0 or automatic. I wondered if this might not have a good effect when things aren't as they should be. I'm guessing (but this isn't quite my field of expertise) if a certain request(s) is causing the process to lock-up, so FastCGI just creates another, whilst leaving the first in place. Somehow it seems only having a single instance allows PHP to move on from the lock-up and the cpu stays under control.

For servers with high-levels of requests setting FastCGI to only a single instance may not be ideal, but it certainly beats the delays I was getting before. Used in combination with WP-SuperCache and WinCache, things seem to nipping along nicely now.

会傲 2025-01-12 03:45:11

查看该任务 mgr 看起来它在每个请求上都缺少缓存。另外,那篇文章的日期是 2008 年,所以很难说所写的说明是否仍然有效。 WP-SuperCache 的某些内容可能会发生变化。

我建议使用 W3 Total Cache。我已经在 Windows Server 2008 和 IIS 7 上对其进行了大量测试,效果非常好。它还与 PHP 的 WinCache 扩展兼容并利用它。如果您感兴趣的话,它还有一些其他很棒的功能,例如缩小、CDN 支持等。它是 WordPress 的一个非常出色的性能插件。您可以在这里获取插件, http://wordpress.org/extend/plugins/w3 -total-cache/

其他一些需要检查的内容...

应用程序池的大小是多少? (进程数?)
确保您使用的是 PHP 5.3。
确保您使用的是 WinCache。
确保将 MaxInstanceRequests 设置为小于 PHP_FCGI_MAX_REQUESTS。绝对不允许 PHP 处理应用程序池的回收。默认为 10K 请求。如果您在负载测试期间看到这些结果,那么这可能就是原因。增加 MaxInstanceRequests 并使其比 PHP_FCGI_MAX_REQUESTS 少 1。

希望有帮助。

Looking at that task mgr looks like its missing the cache on every request. Plus that article dates to 2008 so difficult to say whether the directions as written would still work. Something with WP-SuperCache could have changed.

I would recommend using W3 Total Cache. I've done extensive testing with it on Windows Server 2008 and IIS 7 and it works great. It is also compatible with and leverages the WinCache extension for PHP. Has some other great features too if you're interested, minification, CDN support, etc. It's a really great performance plugin for WordPress. You can get the plugin here, http://wordpress.org/extend/plugins/w3-total-cache/

some other things to check...

What size is the app pool? (# of processes?)
Make sure you are using PHP 5.3.
Make sure you are using WinCache.
Make sure to set MaxInstanceRequests to something less than PHP_FCGI_MAX_REQUESTS. Definitely do not allow PHP to handle recyling the app pool. The default is 10K requests. If you are seeing these results during a load test then this might be the cause. Increase MaxInstanceRequests and keep it one less than PHP_FCGI_MAX_REQUESTS.

Hope that helps.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文