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:
- W3 Total Cache + PHP APC (The site is using database caching, page caching, and object caching with APC).
- 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.
- The site is behind CloudFlare and is using the CloudFlare plugin that corrects IPs for comments.
- 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.
- 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:
-
I installed APC caching (but then again, W3 Total Cache doesn’t cache the Dashboard)
-
I altered my MySQL config to match Matt Mullenweg’s mysql recommendations. http://www.codinghorror.com/blog/files/matt-mullenweg-wordpress-mysql-recommendations.txt
-
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?
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…