One (Wordpress) site goes down, others still up

What is the symptom when the site "goes down"? Do you get an immediate error when you try to access the site, or do you get a timeout after a few seconds?

What exactly does your setup look like? prefork & mod_php? fastcgi? What values do you have for MaxClients and KeepAlive? Any screenshots of "top" when the site goes down?

Anything in the Apache error log? MySQL error log? If the problem only affects one site, the database might be the culprit. Check the tables on MySQL.

You might have to disable the static file option in WP Super Cache and clear the cache in order for the real issues to show up on log files. (I know you're using it because there's a telltale signature at the end of the HTML.)

It's an immediate 500 error. I'm using prefork and mod_php. Error logs are (frustratingly) empty although logging is turned on.

Notable config info:

KeepAliveTimeout 4

 <ifmodule mpm_prefork_module="">StartServers       2
MinSpareServers   2
MaxSpareServers   9
MaxClients       35
MaxRequestsPerChild  4000</ifmodule> 

Your comment on WP Super Cache just made me wonder if that module itself could have something to do with this…?

PHP sometimes has its own error log depending on the setup. Might want to see if that's the reason you don't see any errors in the Apache error log.

@moosetoga:

It's an immediate 500 error. I'm using prefork and mod_php. Error logs are (frustratingly) empty although logging is turned on.
500 with a blank screen is definitely a PHP error. All we need is the error message.

If this is a standard LAMP stack on Debian or Ubuntu, see /etc/php5/apache2/php.ini and make sure that "logerrors" is "on". This will make PHP dump all of its errors to Apache's error log. Restart Apache to apply the new settings. If this doesn't work, you can also specify a different log file using the "errorlog" setting. If you do this, make sure that the log file is writable by the www-data user.

Another option is to enable "display_errors" temporarily. This will simply dump error messages on the screen whenever an error occurs. This is often considered insecure because it might expose the internal workings of your server. But every shared host has this setting turned on, and every self-respecting WordPress hacker already knows the internal workings of a WordPress site, so I'd say the risk is relatively low.

@moosetoga:

Your comment on WP Super Cache just made me wonder if that module itself could have something to do with this…?
You could try disabling Super Cache for a day or two, but that will have a massive impact on performance. Serving a static file is hundreds of times faster than serving a fresh WordPress page.

Thanks for the advice. logerrors was on but displayerrors wasn't so I turned that on. Now I wait for it to happen again so I can hopefully get another clue…