0

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.

  • 1
    Are you checking the slow query log in mysql or connection count? Just off the top of my head I would say mysql might be choking on something. Also, top can show you which processes are going crazy when this happens. – Omnikrys Nov 5 '14 at 16:48
  • @Omnikrys Thanks, will look into this. Still learning how to use WHM/CPanel in a dedicated environment for troubleshooting. I'll update this post as I try things. – Matt Refghi Nov 5 '14 at 16:53
  • Have you considered "bad" plugin(s) that doesnt work in your new environment. Turn half on and see if site hangs, if not turn on other half. Try to keep reducing till you find the problem. You might want to turn on debugging to see what is going on. – user42826 Nov 5 '14 at 17:07
  • @user42826 Yea, definitely. I'm currently doing that procedure again, but with more tries per half, given the inconsistency I observed when I tried it prior. And yep, debugging's enabled. – Matt Refghi Nov 5 '14 at 17:12
  • @Omnikrys Your advice lead me to the solution. Can you post it as a answer? You deserve the rep. – Matt Refghi Nov 14 '14 at 15:51
1

Are you checking the slow query log in mysql or connection count? Just off the top of my head I would say mysql might be choking on something. Also, top can show you which processes are going crazy when this happens.

Here is a bit on the slow query log and different ways to access its information: https://rtcamp.com/tutorials/mysql/slow-query-log/

  • This ended up revealing the issue. I enabled the slow query log with a long_query_time of 1, and repeated the steps to reproduce the issue multiple times. After doing so, I stuck the log file itself into this: code.google.com/p/mysql-slow-query-log-visualizer, and sorted by query time, descending. The top entries in that list were related to Broken Link Checker (wordpress.org/plugins/broken-link-checker), so I tried disabling it. That did it. Couldn't reproduce after I removed that plugin, despite an abundance of attempts. – Matt Refghi Nov 17 '14 at 18:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.