Wordpress(php-fpm)のボトルネックを探る

この記事では、原因を探るためのプロセスをメモしてるので、直接の問題解決に対してのアプローチとしてはいささか冗長であるので、結論を先に書くとプラグインのせいでした。

問題の解決方法だけ知りたい方はプラグインのところまでお読み飛ばしください。

サーバーが重いな...。

と思って$ top -aで%MEM順に見てみると、うちほぼ上位をphp-fpmのプロセスが占めている。しかもそれぞれ10%強ずつほど。

なんじゃこりゃー。

ということで、ひとまず一旦全部のプロセスをkill

sudo kill `ps -ef | grep php-fpm | awk '{print $2;}'`

とか。　

解決策としては下のような案が

php-fpmの設定
Wordpress 4.3的な不具合
プラグインのせい

まずはphp-fpmの設定を見直し

まずはphp-fpmのプロセス管理周りの設定を中心に抑えめに調整してみました。（結論で言えば、これでは解決してません...）

プロセス管理方法

pmでは、プロセスマネージャがプロセスの数を管理する方法をどうするか、を設定できます。

メモリ消費をできるだけ抑えたいので、staticではなく、dynamicにしておきます。ondemandという値もあります。

pm = dynamic

これはdynamicの場合。staticとdynamicについては、

staticは固定値でメモリを保有するので処理速度は高いですが、 dynamicは低負荷の場合メモリ消費量が少ないので、他の処理にメモリを割り当てることでができます。つまり動的にメモリを自動的に制御できます。 via: http://wp.nyumon.club/1468.html

ということらしいです。

最大子プロセス数

子プロセス数の最大値をデフォルトの50から15に減らしておきます。

pm.max_children = 15

アイドル状態の最大プロセス数

アイドル状態のサーバープロセス数の最大値を35 => 15に変更します。

pm.max_spare_servers = 15

各子プロセスの最大リクエスト数

各子プロセスの最大リクエスト回数を調整します。コメントアウトされてるので、追加します。

pm.max_requests = 512

この設定に関しては、

各子プロセスが、再起動するまでに実行するリクエスト数。サードパーティのライブラリにおけるメモリリークの回避策として便利です。再起動せずにずっとリクエストを処理させる場合は ‘0’ を指定します。 PHP_FCGI_MAX_REQUESTS と同じです。デフォルト値: 0 via: http://blog.offline-net.com/2015/05/09/centos-65-nginx-php-fp%EF%BD%8D-memory-tunables/

とのことです。なるほどー。