我还有哪些其他选项可以简化 WordPress 内存利用率?

发布于 2024-12-07 08:48:24 字数 2014 浏览 0 评论 0原文

所以我在试图破解为什么这个 WordPress 安装占用如此多的内存时遇到了困难。我在 MediaTemple DV 4.0 帐户上将服务器从 512 内存升级到 1 GB,这次安装平均使用 60%,如果有人摆弄仪表板,则使用率会跃升至 118%。前端用户没有遇到任何性能问题,站点也没有崩溃,但由于消耗了太多内存,我经常需要重新启动服务器才能进行 FTP 或 SSH 访问。现在,通常情况下,仪表板将挂起一两分钟。这种情况间歇性地发生,但一旦启动,仪表板中的每个页面都会持续挂起,重新启动服务器并不能纠正它(它只是神秘地恢复正常)。另外,我在服务器上安装了其他 WP,但它们在仪表板内部或外部都没有遇到任何问题。他们还使用 CloudFlare 和 AmazonS3,如下所述。我知道对此没有直接的答案,但我很好奇是否有人有任何建议可以提供下一步尝试的建议,考虑到我已经尝试过的内容:

这是安装的内容:

  1. W3 Total Cache + PHP APC(该网站正在使用数据库缓存、页面缓存和使用 APC 的对象缓存)。
  2. 图像资产通过 W3 Total Cache 托管在 Amazon S3/Cloudfront 上。我在 S3 上存储了大约 50,000 张图像,尽管该站点中只有一小部分(大约 1-2k)被积极使用。
  3. 该网站位于 CloudFlare 后面,并使用 CloudFlare 插件来更正评论的 IP。
  4. 我没有在主题(http://www.rokkyuu.com)中做任何特别引人注目的事情。该网站唯一特别先进的事情是,对于来自 WP 的某些图像,如果媒体库中不存在该图像的调整大小版本,WP 会动态调整图像大小,然后将该图像推送到 Amazon S3,以便在W3 Total Cache 取代了路径,前端最终使用 S3 资产。这是为了避免 WP 为每个上传的图像裁剪 8 无数个自定义尺寸。然而,这不会发生在仪表板中。
  5. 这些是我安装的插件:
    • 阿基斯梅特
    • BWP Google XML 站点地图
    • CloudFlare
    • 共同作者+
    • Facebook 页面发布
    • Livejournal Crossposter
    • 重定向
    • 军刀
    • 简单的本地头像
    • 主题我的登录
    • 推特工具
    • 推文搅拌机
    • 用户切换
    • W3 总缓存
    • WordPress 搜索引擎优化
    • WordPress 防火墙 2
    • WP-DB 管理器
    • WP 自定义管理栏
    • WP 隐藏仪表板
    • WPTouch Pro

我尝试做的调试:

  1. 我安装了 APC 缓存(但话又说回来, W3 Total Cache 不缓存仪表板)

  2. 我更改了 MySQL 配置以匹配 Matt Mullenweg 的 mysql 建议。 http://www.codinghorror.com/blog/files /matt-mullenweg-wordpress-mysql-recommendations.txt

  3. 我安装了 xdebug 和 webgrind 并分析了 cachegrind 输出,但我不太确定是什么被视为危险信号。我编写的 PHP 函数很少被列在因总包容成本较高而被称为的项目中,并且在总包容成本最高的地方(php::call_user_func_array),通过 call_user_func_array 调用的函数均匀分布在核心函数和我的函数中。自己的。我提取的主页的缓存研磨样本有 15 MB。另一方面,仪表板中“帖子编辑”屏幕的缓存研磨为 186 MB,而最大的违规者似乎是自定义的“manage_posts_columns”。然而,我删除了所有的manage_post_columns自定义,仪表板仍然挂起,经常无法使用。

我从哪里开始进一步排除故障?

So I've run into a wall trying to crack why this WordPress install hogs so much memory. I upgraded my server from 512 to 1 gb ram on a MediaTemple DV 4.0 account, and this single install is using 60% on average, which jumps to 118% if anyone fiddles with the Dashboard. Users on the front end experience no performance issues whatsoever, and the site isn't crashing, but because so much memory is being consumed, I often have to reboot the server just to FTP or SSH in. And now, oftentimes each page in the Dashboard will hang for a solid minute or two. This happens intermittently, but once it starts, every page in the Dashboard will hang consistently, and rebooting the server doesn't correct it (it just goes back to normal mysteriously). Also, I have other WP installs on the server, but none of them are experiencing any problems in or outside the Dashboard. They are also using CloudFlare and AmazonS3 as I describe below. I know there's no straight answer for this, but I'm curious if anyone has any advice to offer what to try next, given what I've already tried:

Here's what's installed:

  1. W3 Total Cache + PHP APC (The site is using database caching, page caching, and object caching with APC).
  2. Image assets are being hosted on Amazon S3/Cloudfront via W3 Total Cache. I have something like 50,000 images stored on S3, although only a tiny fraction (around 1-2k) are actively used in the site.
  3. The site is behind CloudFlare and is using the CloudFlare plugin that corrects IPs for comments.
  4. I'm not doing anything particularly spectacular in the theme (http://www.rokkyuu.com). The only especially advanced thing the site does is that for certain images coming out of WP, if there exists no resized version of the image in the Media Library, WP resizes the image on the fly and then pushes that image to Amazon S3 so that when W3 Total Cache replaces the path, the front end ends up using the S3 asset. This was to avoid having WP crop 8 zillion custom sizes for every image that gets uploaded. However, this doesn't happen in the Dashboard.
  5. These are the plugins I have installed:
    • Akismet
    • BWP Google XML Sitemaps
    • CloudFlare
    • Coauthors Plus
    • Facebook Page Publish
    • Livejournal Crossposter
    • Redirection
    • SABRE
    • Simple Local Avatars
    • Theme My Login
    • Twitter Tools
    • Tweet Blender
    • User Switching
    • W3 Total Cache
    • WordPress SEO
    • WordPress Firewall 2
    • WP-DB Manager
    • WP Custom Admin Bar
    • WP Hide Dashboard
    • WPTouch Pro

What I've tried to do to debug:

  1. I installed APC caching (but then again, W3 Total Cache doesn't cache the Dashboard)

  2. I altered my MySQL config to match Matt Mullenweg's mysql recommendations. http://www.codinghorror.com/blog/files/matt-mullenweg-wordpress-mysql-recommendations.txt

  3. I installed xdebug and webgrind and analyzed the cachegrind output, but I'm not quite sure what counts as a red flag. Very few PHP functions I wrote are even listed among the items called out for having high total inclusive costs, and where the total inclusive cost is highest (php::call_user_func_array), the functions being called via call_user_func_array are evenly spread across core functions and my own. A sample cachegrind for the homepage I pulled was 15 MB. The cachegrind for the Post Edit screen in the Dashboard, on the other hand, is 186 MB, and the top offender seems to be the custom manage_posts_columns. However, I removed all manage_post_columns customizations and the Dashboard still hangs, regularly unusable.

Where do I even begin to troubleshoot further?

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

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

发布评论

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

评论(2

听不够的曲调 2024-12-14 08:48:24

从干净、全新的 WP 安装开始,然后慢慢添加您正在做的各种事情。如果您在添加内容时观察内存使用情况,您会发现导致问题的部分。

Start with a clean, fresh WP install, and then slowly add in the various things you are doing. If you watch the memory usage as you add things in, you will find the piece that is causing problems.

梦里的微风 2024-12-14 08:48:24

我想我找到了罪魁祸首:

CloudFlare WP 插件和仪表板 = 核崩溃。

我不确定为什么,但在检查了 webgrind 中仪表板页面的内存配置文件后,我发现对 CloudFlare API 的curl 请求导致了内存的巨大峰值。当我从 MediaTemple DNS 禁用 CloudFlare 并禁用该插件后,仪表板开始正常运行。

虽然不确定是否可以在没有 WP 插件的情况下启用 CloudFlare,但出于我的目的,我宁愿拥有一个功能正常的仪表板...

I think I found the culprit:

The CloudFlare WP plugin and the Dashboard = nuclear meltdown.

I'm not sure why, but after examining the memory profile of Dashboard pages in webgrind, I found that the curl requests for the CloudFlare API caused huge spikes in memory. Once I disabled CloudFlare from the MediaTemple DNS and disabled the plugin, the Dashboard started operating normally.

Not sure though if it's okay to have CloudFlare enabled w/o the WP plugin, but for my purposes I'd rather have a functioning Dashboard...

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