|
DMAClinical
|
November 13, 2017 at 1:13 am
We have had some server outages in the past 24 hours, and as a process of elimination – it turns out to be Event Espresso that triggers the server load and memory resources to increase to a point where the server is crashing. Nothing has changed as part of our hosting server, and all has been running fine up until this weekend just gone (Australian Time).
The server reaches MAX resources every time the Plugin is activated. When it’s deactivated – the resources drop back down to a normal operating level.
At this moment, we have disabled the plugin so that the rest of the website can function – and hoping to get some support so we can get this element back up and running normally.
We have purchased a support token, so please see this for more specific details.
|
|
Josh
|
November 13, 2017 at 10:18 am
Hi James,
We’ve received your priority support request and are looking into this now.
|
|
jrengo
|
November 15, 2017 at 9:23 am
Hi,
I’m having this same problem. We updated to the current version of Event Espresso (4.9.50.p) and saw our server overloaded with traffic until it crashed the site. We reverted back to version 4.9.49.p, which worked before the update but is now causing the same issue. We found a link to a patch that supposedly fixes this problem but it lead to a 404 error page. Do you have a fix available? Thanks for your help!
|
|
Josh
|
November 15, 2017 at 9:39 am
Hi there,
While I do not know the exact reason for the load on your site, the other site in this topic had a few runaway options in the wp options table that were causing the heavy load while Event Espresso was activated. After those were deleted the server load went way down with Event Espresso activated. Can you check your site’s options table for the option values with the highest character counts?
-
This reply was modified 7 years, 2 months ago by
 Josh. Reason: added clarification
|
|
jrengo
|
November 16, 2017 at 1:11 pm
Here are the ten largest option values in our wp_options table:
wp_user_roles(autoload: yes, character count: 20408), frmpro_css(autoload: yes, character count: 65986), expresso_db_update(autoload: no, character count: 75452), ee_active_messengers(autoload: yes, character count: 44112), rewrite_rules(autoload: yes, character count: 33375), ewww_image_optimizer_scanning_attachments(autoload: no, character count: 13844), ee_transient_schedule_(autoload: yes, character count: 3588850), _transient_yst_sm_condition_1:573aP_5z7LH(autoload: no, character count: 16411), _site_transien_update_plugins(autoload: no, character count: 14166), _transient_yst_sm_doctor_1:573aP_5wsK2(autoload: no, character count: 167752)
|
|
Josh
|
November 16, 2017 at 1:20 pm
Here’s how you can fix that runaway option:
1) You install these two plugins:
https://wordpress.org/plugins/debug-bar/
https://wordpress.org/plugins/debug-bar-console/
2) These plugins add a Debug > Console item to your WordPress admin bar. You’ll go to that console screen
3) Then add this code to the console:
delete_option( ‘ee_transient_schedule’ );
then you click on “Run”
Then make sure your WP Plugins and WP core software are up to date.
|
