Too much data in wp_options entry where option_name = 'cron' drags down WP

[yannielsen]

Recently I experienced an installation running on a Cloud Server with 10GB RAM, 4 CPU cores being dragged down because of a plugin 'malfunctioning' with cron events.

The plugin created excessive amounts of extra entries in wp_options entry where option_name = 'cron' resulting in a 15,4MB entry in the table.

It wasn't a "endless loop"-error that suddenly resulted in it. It had gone unnoticed for quite some time before it got to the point where the server timed out because the requests to the database simply became too slow.

The plugin should ofcourse not be doing that, but it got me wondering if it was an idea to implement a mechanism to split up the 'cron' entry into multiples when passing a threshold?

[pothi]

Welcome to WP core trac.

if it was an idea to implement a mechanism to split up the 'cron' entry into multiples when passing a threshold?

Of course.

Probably, WP could get some inspiration from ​https://github.com/humanmade/Cavalcade .

[yannielsen]

Thank you @pothi :-) I'm considering just coding this "right away" if noone else is working on it and if it's deemed to be a good idea :-)

[SergeyBiryukov]

Related: #15148

[swissspidy]

In this case, a plugin misbehaved and created a huge cron option. That's not that different to a plugin bloating up the posts table or another option in the database, IMHO.

If you want to "fix" it for cron specifically, I'd suggest going with #15148 or something like Cavalcade.

[peterwilsoncc]

I'm closing this wontfix as #32656 has added committed in [43540] to allow for sites with large cron options to modify cron storage.

@yannielsen The filters added in the commit will allow you to manage cron storage the WordPress way once WordPress 5.0 is released.