運用サイトは基本、nginx＋php-fpm＋mysql（mariadb)をベースにwordpressで動かしています。これが最近急に遅くなったのでチューニングとは言えないくらいの微調整でなんとか戻しました。
nginx＋php-fpmで微調整した話
ちょっと前から徐々にWordpressの管理画面を開くのが遅いなぁ・・・という状況になってきて、投稿をポストしたらエラーが出たりで、こりゃいよいよおかしいな、と思ってチェックしてみました。
便利だったhtop
通常、サイトの挙動が重い、遅いとなると、uptime、free、ｄｆ、topあたりで調べていくのですが、もひとつ分からないので色々調べて1つ見つけたのがhtop。
topの詳細版なんですが、色分けされててソート順とかもF6押したら選べる感じで便利でした。
yum -y install ftop
くらいでインストールできるので、使える方はどうぞ。
最初はphp-fpmのプロセス数を上げてみた
最初はphp-fpmのプロセスが上限いっぱい（普段staticで使っている）だったので、とりあえず上げてみました。
muninのグラフはこんな感じ。weeklyなので08、09あたりを見て下さい。いっぱいですね。
それ以前からプロセスが足りなくなっているのがわかります。
こうなるとさすがにWordpressの管理画面みたいに全部php側に処理が回るものは待たされる事になるので、プロセス数(pm.max_children)を7から１０に上げました。
閑話休題：php-fpmのプロセス数
ちなみに、他の例だとよくここが１５とか３０とかになっているのを見ますが、よほど毎回phpが走るサイトじゃなければそんなにいらないと思います。
WordPressでnginxでキャッシュしながら・・・という前提で考えると、超超メガサイトでWordpressの検索が色んなワードでガンガン来るならまだしも、普通にサイト運営してると検索する人なんてごく少数なんで、新規投稿と忘れた頃（キャッシュが切れてる頃）に過去ページを見に来られる対応くらいで、まぁ１０が最大かと。pm.max_childrenを上げるとメモリも食うので、大体７とかで運用してます。月間数十万PVくらいのサイトでこんな感じ。
さて、話は戻ってこれを１０に上げましたが結局また詰まっています。これは多分２０にしても同じ事が起こる・・・つまりphp-fpm以外に何かボトルネックがある、ということ。結果待たされた分php-fpm側でプロセスの処理時間が伸びてリミットに達する、というはず。
mysql(mariadb)を疑う
WordPressは4.7だかにアップデートしたばかり、php-fpmの問題じゃないとすれば、あとはnginxかmysql。mysqlのグラフが上がっていたのでこちらを疑います。
一応mysqlと大体互換ですよ、というmariadb、my.cnfの設定も共用なのでmysqlの文献が使えます。久しぶりにmysqltuner.plとかも使いながら見てみると・・・結局tmp_table_sizeとmax_heap_sizeが異様に小さい値を設定していたのが悪いっぽい、という結論に。
デフォルトの126Mの倍の256Mに設定して終わり。
そしてmysql側を見てみると・・・
あー、ちゃんと下がりましたね。
で、今はload averageも0.16とかで動いているのでOKでした。