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.
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.
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)
Our server process manager is reporting that the member directory plugin is using a defunct php call when the pagination link is clicked. Have not checked blog directory for same behavior, yet.
Perhaps it could be in order for a developer to take a fresh look at the commands used in these plugins?
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.
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. ??
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.... ???
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?
5571 pointsLike some sort of WPMU DEV GodMindblowingly helpful memberLifetime member
Support Kangaroo
—
4th February 2012 (3 months ago)
#
Greetings SooBahkDo :-)
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
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" :) and to their heart's content without triggerring any errors. :)
Responses (12)
Member — 19th January 2012 (4 months ago) #
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)
Suggestions?
Thanks,
Phil D
Member — 19th January 2012 (4 months ago) #
Additional info.
Our server process manager is reporting that the member directory plugin is using a defunct php call when the pagination link is clicked. Have not checked blog directory for same behavior, yet.
Perhaps it could be in order for a developer to take a fresh look at the commands used in these plugins?
Phil D
Sales & Support Pro — 19th January 2012 (4 months ago) #
Hiya Phil,
Can you tell us what that defunct PHP call is please? Given that I can dig deeper...
Thanks,
Phil
Member — 19th January 2012 (4 months ago) #
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.
Thanks,
Phil D
Sales & Support Pro — 19th January 2012 (4 months ago) #
Thanks for those screenshots. The <defunct> bit isn't anything I've seen before.
What version of PHP are you using?
I'm going to ask the developer if any of that sounds familiar.
Thanks
Member — 19th January 2012 (4 months ago) #
Wordpress 3.3.1
MySql 5.1.56
PHP 5.3.8
Member — 20th January 2012 (4 months ago) #
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
Member — 21st January 2012 (4 months ago) #
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
Member — 21st January 2012 (4 months ago) #
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
Member — 4th February 2012 (3 months ago) #
Hello,
Update on the 500 errors with these plugins active here:
http://www.soobahkdo.biz
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.
http://premium.wpmudev.org/forums/topic/shared-ad-will-not-appear-at-bottom-of-members-directory
Thanks,
Phil D
Support Kangaroo — 4th February 2012 (3 months ago) #
Greetings SooBahkDo :-)
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 :-)
Member — 18th March 2012 (2 months ago) #
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" :) and to their heart's content without triggerring any errors. :)
Thanks,
Phil D
Become a member