High CPU Load After Update to v4.3

@compute

Thx, but after activating the plugin “wp crontrol” shows furthermore the following https://take.ms/FeW9t I do not know why and what to do :/

@hummelmose Its just a normal plugin. It stops WordPress 4.3 from keep spamming the cron option – but it does not remove the currently wrong cronjobs (will do soon if a 4.3.1 is not around the corner).

@rené Yes the plugin only stops the new spam cronjobs. The idea is to remove the current spam cronjobs if the plugin gets approved to the .org directory anytime soon.

@compute – But with the fix in Taxonomy.php and the cleanup in my DB I don’t need it right ?

@hummelmose Right ?? This is just a fix without hacking the core files.

Thanks – I expected that.

But great you make a version that easily can clean up the “mess” ??

The fix does not create load.

The hell it doesn’t. Once I finally figured out that I needed to delete it a few seconds after it started running (or else it would spawn hundreds of more instances, as more users visit my site) – and even AFTER I added a sleep to that script, it still caused heavy load on my server for over an hour before I abandoned that method and just went in and edited the database manually. I think you fail to realize that servers effected by this issues have 1000s of these damn cron jobs to get rid of, and looping through them while the server is under load is just asking for trouble… especially if each visitor to the site causes another loop job to be spawned.

On top of that, this “Fix” was available on Wednesday, yet for some reason it has not been implemented in the 4.3 code which is currently available from WordPress. Which means 1000s more sites are being needlessly effected by this bug each day. I didn’t install 4.3 on my site until Thursday, the day after this bug was fixed.

Fair enough. Thousands and thousands of entries, I have not seen. In my instance, it only had maybe 400 entries, and was cleaned up in under a few seconds.

Here is alternative code which does the same operation without making a database call for every single entry.

<?php
function clear_bad_cron_entries() {
	// Fix incorrect cron entries for term splitting
	$cron_array = _get_cron_array();
	if ( isset( $cron_array['wp_batch_split_terms'] ) ) {
		unset( $cron_array['wp_batch_split_terms'] );
	        _set_cron_array( $cron_array );
	}
}
clear_bad_cron_entries();

Try this one instead if you’re having problems with the first one. Note that the first one does work, but yes, it will cause lots of SQL to be run to fix the issue. This one does the same thing in one pass, with only one SQL statement.

On a multisite, will running the upgrade network be sufficient for running the mu-plugin on every site or will we need to actually load each site?

On a multisite, if you update to 4.3.1, then the “upgrade network” process will do the job for you there. The code in my last post here is the new code that will be included in 4.3.1 to clean this mess up.

If you are trying to clean it up now, and you are using the above code in a mu-plugin, then “upgrade network” will essentially cause a ping to each site which *should* run the mu-plugin code as well. However, if there is nothing for it to actually upgrade, then I don’t believe it will actually ping each site.

The above code should cause no additional load, since it’s performing only one query to get the cron data, and one additional query to save it back, if it needs to remove the extra entries. So, you can leave it running for a little while and allow normal traffic to the sites to clear the problem up for you.

Just want to say thanks to Samuel for posting this.

Our site – https://www.thesportreview.com – was super slow after the 4.3 update – and this fixed it in an instant. Much appreciated.

Martin

We are litereally mentally exhausted for about a week trying to solve the root of the problem. We changed theme, disabled plugins, return to default theme… Nothing worked. Nothing! Finally, this topic solved the issue.

I just hope that WP 4.3.1 comes out soon and fixes the problem good.

By the way, WordPress should really abandon prior MySQL 5.5 versions. And for the PHP, the minimum should be 5.4.

i give so many +1s for this fix. this took down my site daily since i updated to 4.3. a very sincere thank you!

@samuel Wood (Otto): How to run script “fix.php”. Sorry, I’m a newbie.

Solved with two steps.

Thanks.

@vi3t it’s clearly stated in his post on page 1. Read it again.

Thank you millions for this fix. What is the actual reason they haven’t pushed out 4.3.1 yet? I can’t believe it. Who makes these decisions?