WP4.3.0にCPU負荷とメモリ消費が増加する不具合？対処してみた

WordPressが重かった原因として、4.3.0の不具合があったようです。

WordPress4.3.0に不具合発見？

WordPressが重くて困って、別環境を用意して何とか復帰…でも、原因は結局分からず。

そんなところに、こんなツイートを見つけました。

当サイトでも使っているテーマ「STINGER5」の製作者の方です。

メモ。 / “WordPress 4.3でCPU高負荷になる重大なバグあり。直し方を一応解説。 – http://t.co/Nvn4cxH5Qv” http://t.co/FA73sqFqev

— ENJI (@ENJILOG) September 5, 2015

ENJOYPCLiFE.NETさんの記事に「4.3でCPU後負荷になるバグがある」というのがあるとのこと。

ENJOYPCLiFE.NET

 

139 Posts

441 Shares

50 Users

79 Pockets

WordPress 4.3でメモリ消費量増大・CPU高負荷になる重大なバグあり。直し方を一応...

http://enjoypclife.net/2015/08/31/how-to-fix-wordpress-4-3-high-cpu-load/

WordPress 4.3でサーバーのメモリ消費量が異常に増えたり、CPUが高負荷になる重大なバグ/不具合に遭遇しました。4.3に更新後、プラグイン等の問題を排除しても、異常にサイトや管理画面が重い、レスポンスが悪い際にご一読ください。

当サイトも8月19日頃、WordPressを4.3.0へアップグレードしていました。

CPUの高負荷と、メモリ消費量増加は23日頃に発生しているので、WordPressのアップグレードとの関連性はあまり考えていませんでした。

でも、リンク先の記事の、アップグレード後に管理画面が重くなってメモリ不足やらサーバーエラーが頻発、と自分の悩んでいた状況に似ています。

どうやら、「wp-includes/txonomy.php」の4,448行目、スケジュールの登録を行っているところの、第一パラメータと第二パラメータが逆になってしまっていているようです。

cron.phpで処理されていくはずなのですが、パラメータが逆になっていることで、処理できないキーが登録されている感じでしょうか。

function _wp_check_for_scheduled_split_terms() {
if ( ! get_option( 'finished_splitting_shared_terms' ) && ! wp_next_scheduled( 'wp_batch_split_terms' ) ) {
wp_schedule_single_event( 'wp_batch_split_terms', time() + MINUTE_IN_SECONDS );
}
}

UNIX時間が第一パラメータで、第二パラメータに「wp_batch_split_terms」を指定するのが正解とのことです。

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

どんどん登録されるスケジュール

リンク先のWordPress.orgのトピックでは、修正をした上で、不要なキーの削除方法が書かれています。

これを見ると、DBのcronのパラメータを取得して、誤って登録されたキーのものを配列から削除してセットし直すという流れのようです。

$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 );
}

とりあえず、削除する前にこの配列を表示してみようと思います。

リンク先ではmu-pluginsディレクトリを作成して、その中にphpファイルを作成して実行させる方法が書かれていますが、自分的にはこの実行方法は馴染みが薄いので、プラグインとして登録してみます。（ソースは下の方に。）

プラグインを有効化すると、メニューに「Pz CronCheck」が追加されるので、押すと _get_cron_array() で取得したcronのスケジュールの配列が表示されます。

では、早速表示を。

って、うわあああああああΣ(ﾟロﾟ)oﾞ

通常がどのくらいか分かりませんが、配列数が1万6千個を超えているようです。スクロールバーが遥か遠くまで続いています。

中身を見てみたところ、「SNS Count Cache」の取得とかをスケジュールしているのが入っているようです。

というか、UNIX時間（エポック秒）を見てみると、「1440288206」＝「2015/08/23 09:03:26」とかから残っているようです。

そういえば、「予約投稿」とかあまり使っていないので、cron.phpの通常実行を無効にして、サーバーの方から30分ごとに実行するようにしていました。

これは、スケジュールを沢山登録するプラグインを使うようになったのに、cron.phpの実行頻度が減って処理しきれなくなった、というのもありそうです。

不具合どうこうと別に、自分の設定がかみ合っていなかったようです。

正常な状態のWordPressで表示すると、一画面で収まる程度でした。

ここから記事を表示させたりすると、無意味（？）なスケジュールがどんどん増えていきます。

UNIX時間がキーになっていないので、消化できないのかも知れません。

とりあえず、修正案のとおり、「taxonomy.php」を修正してみたところ、増えなくなりました。

今度は登録されてしまっているスケジュールを削除します。

 $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 );
}

こんな感じのコードで、

1. cronの配列を取得
2. キーが「wp_batch_split_terms」になっているデータがあったら
3. 配列から削除する
4. cronの配列に戻す

ということをやってくれるようです。

こっちの「cronのスケジュールからキー削除」もプラグインに組み込みました。

「Pz CronClear」を押すと、確認無しで実行します。

削除後。あくまでも「wp_batch_split_terms」がキーになっているデータが削除されるだけです。

UNIX時間がキーになっているものは沢山残っていますが、自然に「cron.php」が処理してくれるので、しばらく放置すると良さそうです。

普段は不要なプラグインとなるので、「停止」しておきましょう。

WordPress 4.3.1で対応されるらしいので、更新したらこのプラグインは削除してしまって良いと思います。

用意したプラグインのソース

「wp-content/plugins」ディレクトリ配下に、プラグイン用の適当なディレクトリを作成して、ファイルを作成します。

自分は「wp-content/plugins/pz-croncheck.php」という感じにしました。

<?php
/*
Plugin Name: Pz-CronCheck
Plugin URI: https://popozure.info
Description: cron schedule check for WP4.3.0
Version: 0.1
Author: poporon
Author URI: https://popozure.info
License: GPLv2 or later
*/
if (is_admin()) {
add_action( 'admin_menu', 'Pz_CronCheck_add_menu' );
}
function Pz_CronCheck_add_menu() {
add_menu_page( 'Pz Cron Schedule Check', 'Pz CronCheck', 'manage_options', 'pz_croncheck_check', 'Pz_CronCheck_check' );
add_menu_page( 'Pz Cron Schedule Clean', 'Pz CronClear', 'manage_options', 'pz_Croncheck_clean', 'Pz_CronCheck_clean' );
}
function Pz_CronCheck_check() {
$cron_array = _get_cron_array();
echo '<div class="warap"><h2>Cron Array</h2><table style="border: 1px solid #000;"><tr><td>';
print_r($cron_array);
echo '</td></tr></table></div>';
}
function Pz_CronCheck_clean() {
$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 );
}
echo '<div class="warap"><h2>Cron Array After</h2><table style="border: 1px solid #000;"><tr><td>';
print_r($cron_array);
echo '</td></tr></table></div>';
}

「あちこちのサイトでソースを拾ってプラグインのファイルは作ったことあるけど、mu-pluginsとかってなんだ？」という方向けに用意してみました。

ちなみに、配列の量が少なければ、print_r を <pre>～</pre> ではさんであげると、少し見やすくなります。

echo '<div class="warap"><h2>Cron Array</h2><table style="border: 1px solid #000;"><tr><td>';
print_r($cron_array);
echo '</td></tr></table></div>';

↓

echo '<div class="warap"><h2>Cron Array</h2><table style="border: 1px solid #000;"><tr><td>';
echo '<pre>';
print_r($cron_array);
echo '</pre>';
echo '</td></tr></table></div>';

ZIP形式でも用意してみました

[2015/09/07追記]

一応、ZIP形式でも用意してみました。

[wpdm_package id=’8875′]

プラグイン→新規追加→プラグインをアップロード→ダウンロードしたZIPファイルを選択→インストールとしてください。

あくまでもcronのスケジュールを確認して、誤ったキーを削除するだけで、根本的に解決するものではありません。

taxonomy.php を修正しない限りは、誤ったキーもすぐに作成されてしまうと思います。

「これも難しい！」という場合は、4.3.1がリリースされるまで、4.2.xに戻すのが良いと思います。

では(^-^)o