WordPress High CPU Load Bug After 4.3 “Billie” Upgrade and How to Fix it

Usually a blog is managed by a blogger who isn’t very tech savvy- and if you totally believe in the WordPress community for fixes and updates, then believe me, you are screwed this time. We have tech team here and we carefully install updates after validating it in staging area, but we never thought someone’s extremely stupid change would cause such pain.

After we upgraded to 4.3 our CPU load slowly started increasing and next day it was 9.0, whereas we had just 2 cores and ideally it remains somewhere near 1.9. We disabled plugins which were taking more CPU juice and for a moment it came down, but the next day it was again crossing 10.0 and things started getting worse, php-fmp socket timed out and our site became super slow. We upgraded to 4 cores and things were normal for few days. Once again same things happened and it was really irritating. Finally, we applied the WordPress high CPU load bug fix and thing are back to normal.

Here is what happened to us due to this WordPress high CPU load bug –

We had believed in the WordPress community for WordPress core updates and we suffered big time- and many others are still doing the same. This article is written to make all the bloggers on WordPress aware about this serious WordPress high CPU load bug and guide them towards a “hot fix”. I have seen in forums how people have cried over their server getting screwed.

This is why it happened –

https://core.trac.wordpress.org/changeset/33646/trunk/src/wp-includes/taxonomy.php

Author “dd32” has reversed the argument while fixing term-splitting routine on new installations and he screwed up. The reversed arguments passed to  wp_schedule_single_event() were causing invalid entries to the WP Cron system.

The question is- why it didn’t come in the code review or does WordPress code go live without testing or code reviews? Well, God save us the next time we upgrade WordPress. Anyways, here is the “hot fix” from Samuel Wood (Otto) for those who are still suffering. Make sure you put your site under maintenance and apply these changes to solve WordPress high CPU load bug-

Step 1. Fix the actual issue by applying part of the patch in that ticket. It’s a one-liner. Open the wp-includes/taxonomy.php file, and go to line 4448. This is that line:

wp_schedule_single_event( 'wp_batch_split_terms', time() + MINUTE_IN_SECONDS );

The problem is that the arguments are reversed. Switch them, like so:

wp_schedule_single_event( time() + MINUTE_IN_SECONDS, 'wp_batch_split_terms' );

That will fix the underlying issue, but it won’t stop the load. To do that, we’re going to make a temporary mu-plugin.

Step 2. Navigate to your /wp-content directory. Create a subdirectory called “mu-plugins”, at /wp-content/mu-plugins. The name of the directory is important. If you already have that directory, just go in there.

MU Plugins are “must use”. All PHP files in this directory get auto-included by WordPress. It’s a handy way to run some code in your WordPress instance without having access to the Plugin page to activate plugins.

Create a new file called “fix.php” or anything, the name doesn’t matter. This will be the contents of that file:

<?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();

This is the same code in 4.3.1 to clean up the problem and you need it for running. So, paste that code into the fix.php file, and save.

Now, navigate to your site. The problem should clear up shortly. Once it does, you can delete the fix.php file. It only needs to run once, not every time your site loads.

If you are using multi-site, then you need to load every site at least once to allow this code to run on all of them. Cron jobs are stored per-site, not per-instance.

For more follow this thread – https://wordpress.org/support/topic/high-cpu-load-after-update-to-v43. To know more about 4.3 disasters have a look at https://wordpress.org/support/topic/read-this-first-%E2%80%93-wordpress-43-master-list?replies=3&view=all.

Hope it would help someone still facing WordPress high CPU load issues after migrating to WordPress 4.3. Please let us know in comments below.

Read our story: One Year of fossBytes – Yesterday, Today and Tomorrow