jotsheet

My site is hosted with Pair. Recently, I had been having lots of problems with PHP exceeding the allocated 16 megs of memory and being killed by Pair’s monitoring scripts — sometimes 3 or 4 times an hour.

I fixed the problem and thought I’d share for anyone else in my situation.

Don’t run WordPress under php-cgiwrap

This is the real fix. The two items below seem to help, but this is the solution: don’t take Pair’s advice and run WP under php-cgiwrap. When using php-cgiwrap, WordPress turns into an incorrible memory hog.

php-cgiwrap offers added security, since WordPress will run as your user on the box, allowing you to chmod important files (e.g. wp-config.php) to 600. However, the benefits of the security are outweighed in this case by the fact that it just makes your site kinda unreliable.

When you switch to the normal WP/PHP situation — running PHP as an Apache module — you’ll need to relax some of the permissions in wp-content/ and WP’s cache/ directory. You also need to make wp-config.php world-readable (the nobody/www user has to be able to read it). This isn’t a problem for accessing the file from the Web — the database settings are hidden in PHP variables, not exposed to a Web user — but if you’re skittish, you can require() the database values from an external file.

Use WP-Cache

Well, it’s almost a given these days. Has to be the most useful plugin for WordPress, but this alone couldn’t save my PHP process under php-cgiwrap — even when I bumped the expiration time up to 12 hours.

Disable WordPress’ internal cache

I don’t know if this helped, but it didn’t seem to hurt. And from this thread, the WP cache seems like a bad idea, anyhow.