Members Directory, Blogs Directory Crash Site

Hello All,

We have WPMUDEV Members Directory and Blogs Directory active on a site and when users click from one to the other too quickly it causes a 500 server error. (its a customized 500 error message)

As long as users do not get impatient (HAHAHAHAHA) and click too quickly from Biz Members to Biz Sites to Locations, the server recovers and stays happy. However, a couple of quick clicks and all hope is lost.

The server may also return a 500 error when a search is performed on either directory page.

You can click the menu links and crash the site here :slight_frown:

Watching server load when either Directory page is viewed, CPU use goes to 100% and thats when the 500 server error occurs.

Is there a way to throttle the CPU time these scripts consume?

And/or to limit the qty of page results they retrieve?

Any other suggestions?

Phil D

  • SooBahkDo

    So the server 500 errors continue and I found the following comment about max CPU use on a hosting provider forum:

    "Work out what part of the processing is causing the problem. If it is database lookups then index the database properly so that the lookup works properly. If it is a badly written script then toss it out and use a properly written one.

    Well written scripts and properly indexed databases should never use more than a small fraction of the CPU limit. "

    I would hope that Memory Directory and Blogs Directory are well written, but turning them off solves the problem, soooooooo reckon some database indexing needs to be performed? Should I have some other indexer plugin running?

    I am running Post Indexer and Commment Indexer for some other sitewide functions, but do not recall an indexer plugin being required for these directories to work properly. (We are running Avatars)


    Phil D

  • SooBahkDo

    Hi Phil,

    The only thing I saw was the message PHP defunct appearing briefly in our server process monitor.
    Refer to screenshots.

    I was observing the server process monitor as I executed the Member Directory, then the Blog Directory in rapid succession, so I had to catch what I could by screenshot. Details are certainly not complete. Someone else surely has the tool set and skills to monitor these scripts and server interaction in real-time to better understand what is going on.

    In addition to the PHP defunct message, is it possible that clicking either directory script starts a cron job and if that cron job has not completed before a user clicks again, clicks the other script or performs a search on either directory page, that conflicting cron job instructions could cause the 500 error? These are the actions that I observe cause 500 errors.

    Phil D

  • SooBahkDo

    Additional clarification on this issue.

    When the main site throws the 500 error, all the subsites still work.
    Only the main site presents the error.

    In some cases the error will not resolve until I rename the plugin directory and access the main site, then change the plugin directory name back.

    So the whole server does not appear to be crashing just the main site, but it is the only one where the Members and Directory plugin are running.

    Any reader with skills for hire who can help resolve this is welcome to chime in.

    Phil D

  • SooBahkDo

    It seems that the query on a small installation like this one should not max out the server when it executes.

    Hmmmmmmm soooooooo absent a fix for that problem how about a workaround code snippet to prevent overlapping queries or cron jobs when a user clicks from one to the other too quickly - or whatever is eating up the cpu?

    If the Members Directory and the Blogs Directory trigger a cron job, then perhaps the code in each should check to see if a cron job is already running before its cron job begins. ??

    Grasping at straws here...

    Surely there is a fix here somewhere.

    Phil D

  • SooBahkDo

    Additional observation:

    When the 500 server error message appears, if the user takes no action then the error become permanent and cannot be resolved by the user.

    HOWEVER, in 9 out of 10 cases when the 500 error message appears if the user quickly clicks their browser back button twice or more, the error will resolve and the site remains usable.

    Why would "quickly" clicking the browser back button resolve the issue? But clicking it too late will not.? Unless the quick back button action is "undoing" the offending action before.... ???

    Phil D

  • SooBahkDo


    Update on the 500 errors with these plugins active here:

    We upped the php memory to 576 megs.
    We discovered a couple of user blogs with a visitor map plugin active that was very "heavy."

    We deactivated that plugin sitewide and left the memory high for now.
    So far no one has reported any 500 errors and no errors related to these plugins have appeared in the server logs.

    I may experiment with lowering the memory slowly, but what is the negative for just leaving the memory limit high?

    I would still like to see the issues discussed in this thread resolved for these plugins.

    Phil D

  • aecnu

    Greetings SooBahkDo :slight_smile:

    I am happy to see that you have things working somewhat to your satisfaction - your not getting 500 errors.

    Being from the background of Global Network Administrator of Multiple Server Network both US and Europe, we do not mess have a single server running PHP 5.3 or above

    As a matter of fact most are 5.2.14 and a couple are 5.2.17

    There are many reasons for this but primarily when we try to upgrade to 5.3+ everything goes fine with the upgrade but all hell breaks loose on our clients sites and we ended up rolling it back and peace and harmony once again become the norm reigning the server landscape.

    Symptoms that you have given further address my concerns about PHP 5.3+ to include Memory issues, switching or clicking too fast .... lol etc. that you have indicated.

    I would happily dig deeper into your query if I had a server that ran PHP 5.3+ but to date we are not going there with our servers so obviously I am not able to test these very plugins you describe in your type of server environment - or at least not at this time.

    A quick test on our production platform (PHP 5.2.14) of these two plugins results in no problems what-so-ever no matter how fast I click and the PHP Ram ceiling is set at 256, nor does it result in high server loads.

    Therefore I am not saying that this is the problem for sure because I have no way to prove it out ..... but it sure seems that this is the inclination :-S

    Joe :slight_smile:

  • SooBahkDo

    Hello All,

    We upgraded this VPS to 8 Gigs of ram and made some server modifications, fastcgi tweaks and a few other tweaks and this issue appears to have been eliminated. Memory is set at 256mb local and 576mb master.
    WP 3.3.1
    MSQL 5.1.61
    PHP 5.3.8
    There was a bug in CPanel with Fastcgi process handling and for which we applied a workaround, but unfortunately we changed so many things at once, that I am not able to report exactly what the primary contributing factor was that caused the server crashes when accessing the directory pages. However, the CPanel / fastcgi bug was preventing activated processes from being killed and I suspect that multiple accesses of the directory pages resulted in tons of running processes that consumed all the server memory and generally overloaded the server. Even without the directory related crashes, the Cpanel / Fastcgi bug resulted in a steadily escalating quantity of active processes until they consumed all available server memory over about a 1 week period. Rebooting the server would start the memory escalation cycle over again. After applying the workaround, memory use is as expected and stable.

    At this time, users can "click as fast as they want" :slight_smile: and to their heart's content without triggerring any errors. :slight_smile:

    Phil D

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.