Cron Job Maxing Out RAM

Hi,

I already replied to you by email, but I’ll repost some info here for other people future reference.

Under normal circumstances, unless you have millions or at least a few hundred thousand of cron jobs, it’s unlikely to cause 503 errors or maxing out the RAM.

Exception would be, if your server php.ini memory limit is really low (such as on some shared hosting plans) and if your site was already approaching that limit.

Cron jobs are serialized into one field on WordPress, and they need to be fetched into memory before execution, which adds to the total amount of RAM already in use.

For example, if you have a limit of 48 MB on PHP and your site is already using 46 Mb in average, a smaller list worth 2 Mb of cron jobs could cause that.

The key here, is the amount of memory you have and the amount of duplicate cron jobs you have, as well as the total amount of memory already used by WordPress, regardless of the cron jobs.

—

Unfortunately, adding duplicate cron jobs was a bug introduced on version 2.6.0 and it was fixed on version 2.6.1 https://www.ads-software.com/plugins/fast-velocity-minify/#developers however, if you never updated the plugin, it would keep on accumulating.

You may have deleted the plugin, or even reinstalling it, but while there is nothing to run on those cronjobs, WordPress still needs to get a list of cron jobs, which is where it could fail.

I’ll explain below, what you can do to remove everything related to FVM, including the cron jobs, cache files and plugin settings.

The first thing to try is the Fast Velocity Minify Cleaner plugin, available on https://github.com/peixotorms/fast-velocity-minify-cleaner/

Just download the zip and upload it via wp-admin, then follow the instructions provided on that github page.

—

If the above fails, the absolute manual steps would be:

a) Ensure the plugin is deleted completely from the site.
b) Delete the wp-content/uploads/fvm directory, recursively
c) Delete the wp-content/cache/fvm directory recursively
d) Check your prefix database on the wp-config.php file
e) Export the yourprefix_options table via phpmyadmin?
f) Delete all fields starting with fastvelocity_ on yourprefix_options table via phpmyadmin

You can see that the option_name cron has serialized data, so you cannot simply delete it like that.

You can upload it to google drive and send it to me.
You need not to worry, as it should not include any personal data about your site.
If you are proficient with reading SQL you can also send me only the cron field data.

I’ll send you a new SQL query to resave only your other existing cron jobs, without the duplicated cron jobs generated by FVM 2.6.0 version.

This is needed, because rather than running a delete, you need to update it with the correct cron jobs. The data is all serialized inside a string.

—

Do NOT delete all our cronjobs by running
DELETE FROM wp_options WHERE option_name = ‘cron’; as this will delete all cronjobs, including the default wordpress ones and other plugins cronjobs, which may be needed for the site to work properly.

Kind regards,

Raul Peixoto

• This reply was modified 4 years, 7 months ago by Raul P..

The developer above assisted me in troubleshooting the issue by email, and the issue was eventually resolved.

Zend OPcache, a caching system, was enabled for PHP. Flushing or disabling OPcache did not help; I had to:

– Install the FVM plugin again to each affected site
– Very quickly, while only one instance of fastvelocity_purge_old_cron_event cron job was visible (before it replicated itself to thousands of entries), change that one cron job to “non-repeating” and immediately delete it
– Immediately disable the FVM plugin.
– Flush the OPcache (using the WP OPcache plugin)
– Delete the FVM plugin.
– Turn off OPcache
The steps have to be done very quickly before fastvelocity_purge_old_cron_event starts replicating itself again.

The issue was on two of our company’s websites. We have business hosting with four sites on one server. Three of the websites had Fast Velocity Minify. Two had version 2.81 installed, and the plugin had been deleted from the other site months prior. fastvelocity_purge_old_cron_event would replicate itself to over a thousand jobs within minutes, and several instances would attempt to run simultaneously.