Rex V

@dancarter213 I had the same problem after the update on a staging site with memory limits applied (max 256mb, as is common on some client sites); WordPress seems to be rather inefficient in clearing the cron queue, and it would generate out-of-memory errors when trying to clear the queue.

If you have access to your database, removing the ‘cron’ value should probably fix your issues, e.g. like so (assuming a default prefix):

DELETE FROM wp_options WHERE option_name = 'cron';

If you have no direct access to the database, but can access the files, temporarily renaming the sunshine-photo-cart plugin directory can return your access to the site. Then, you should try and remove the option named above, possibly using a plugin that allows you to directly edit/remove wp_options records.

• This reply was modified 4 years, 11 months ago by Rex V.

Some additional information: what the current code does, it schedules your custom function to run every page load. The consequence of this is the following:

– sunshine_session_garbage_collection runs once on every page load;
– The WordPress cron option is updated every page load.
– The WordPress cron option contains an ever growing list of moments at which to run the sunshine_session_garbage_collection action. As each update of the cron option involves a serialize and unserialize action, this causes the update to become more expensive which each load, causing significant strain on busy websites. The option at my client’s website is currently over 5 million characters and counting.

So in addition to fixing the issue outlined above, you should probably make sure that any extra scheduled tasks are removed from cron. In my clients case, this cannot be done using repeated calls to wp_unschedule_event, as those are very inefficient and will cause memory or timeout errors due to the huge size of the cron option.

I’m testing some code to clear the cronjobs, will update later.

• This reply was modified 4 years, 11 months ago by Rex V.
• This reply was modified 4 years, 11 months ago by Rex V.

With the changes suggested above, some pages still seem to have slow loading times. Could this perhaps be due to other meta keys? (such as sunshine_image_view, which in this case also has 157220 entries)

Hi,

Good to hear that the suggested change made such an impact! I’m currently looking for other bottlenecks in the software. One seems to be in the page where the galleries are called from. The following query has a load time of 13 seconds:

SELECT post_id, meta_key, meta_value
FROM wp_postmeta
WHERE post_id IN (18113,17916,17815,16820,16795,16746,16576,16348,15836,15540,15324,14969,14672,14532,14485,14410,13684,12808,12735,12353,11066,10890,10751,5932,10688,5975,10614,10288,358,734,745,3669,1152,1228,1613,1687,2497,2103,2678,2862,2966,3110,3873,4554,4688,5081,5216,5299,5391,5618,5659,6026,6142,6850,7624,7972,8092,8327,8353,8730,8800,9176,9545,9742,9855,9977,10025,11208,11618,11712,11808,12021,12240,12083,12290)
ORDER BY meta_id ASC

Which is caused by this chain of calls:

update_meta_cache
-
update_postmeta_cache
update_post_caches
WP_Query->get_posts
WP_Query->query
WP_Query->__construct
sunshine_get_galleries
require_once('/plugins/sunshine-photo-cart/themes/theme/home.php')
load_template
SunshineFrontend::get_template
SunshineFrontend->sunshine_content
apply_filters('the_content')
the_content
include('/themes/photome/page.php')
require_once('wp-includes/template-loader.php')
require('wp-blog-header.php')

I’m trying to determine what the page does but editing the page gives me an error (due to timeout).. I’ll do some benchmarking to determine the cause of the slowdown.

• This reply was modified 9 years, 3 months ago by Rex V.