Basically, I've got a new dedicated server, and I'm testing the migration over to that server. The site (WordPress-based) seems to work fine, but I noticed that sometimes, I can put the server in a state where it hangs for many, many minutes at a time. While in this state, I can tell via Apache Status that my requests are stuck in a waiting state. Any additional requests at the same time get the same treatment, and hang. (Others seem to be able to access the website while this is happening, I believe the one that triggers the hang is the only one that feels it.) When it eventually recovers from this state, I've seen two outcomes:
- It loads, and I can tell it spent a lot of time processing PHP by looking at something we log in the footer.
- It throws a 500 error.
The best way I've found to reproduce this is to try and activate absolutely all my plugins at the same time. I have 58 plugins total, which is a lot, I know. Normally, they're not all active at the same time, some are temporarily activated and then deactivated - but in this scenario I don't care, I activate them all because the purpose is to trigger this hang. And, in my previous shared environment, I never encountered this hang, despite having more plugins in the past, for many years. But anyway, it seems when I activate all plugins at once, there's roughly a 75% chance that the request will hang in Apache.
I noticed that when this hang occurs, if I run this:
UPDATE wp_options SET option_value = '' WHERE option_name = 'active_plugins';
And then refresh the hanging tab in my browser, it immediately recovers and loads instantly. This, to me, suggests that the problem lies within WordPress, it's not something my host can figure out.
In an effort to identify the one particular plugin that's causing the issue, I've tried activating a subset of the plugins at a time. When I noted the hang, I did the DB fix, and then only activated a subset of that subset. But, weirdly, I wasn't able to zone in on one plugin that always triggered the hang. It wasn't consistent, so I couldn't identify a specific culprit.
I also tried, just to be safe:
- Increasing php.ini settings (max_execution_time, max_input_time, memory_limit, post_max_size)
- Increasing Apache config settings (keep alive)
No luck. WordPress version is 4.0, by the way, and the plugins are always up-to-date.
Any ideas what might be causing this? Here's what I'm thinking of trying next:
- Trying to find the culprit, but this time doing the opposite. Prove without a doubt that a certain set of plugins, when activated, never trigger this hang. Then, one of the other plugins must inevitably be to blame. Basically the key here is to increase my tests per subset - if it doesn't happen consistently, maybe a plugin introduces the chance of it happening. I'd need more tests to be sure, simply.
- Looking for an easy way to determine which PHP or Apache modules might be required by these plugins, that my shared server might have had, but are not yet enabled on the dedicated. W3TotalCache, for example, was great in that it provided a compatibility check; I noticed some differences and corrected them. But how does one approach this for all plugins?
- Maybe some of my plugins are silently having a hard time with the new PHP version on the dedicated. 5.3.20 previously, now 5.4.34. How to identify which ones if they're not being vocal via warnings or errors?
UPDATE: The hang just occurred on deactivate.