kusanagiを非推奨の環境であるt2.microに
推奨RAMが4GB以上のところ、t2.microは1Gしかないので、すぐスワップアウトする。
良い機会なのでちょっと勉強してみた。
- kusanagi php7 のオプションでphp7にしているのと同じ状態
- 動作環境はWordPressの最新版
- 内容は実運用データを入れたもので、そこそこ重くなっているものでテスト
疑問だったこと
- nginxの同時接続数とFastCGI(fpm)の間の関係
- Apacheのmoduleの時は理論上の最大RAMが[Apacheの同時接続数]x[php.iniのmemory_limit]だったが...？
同時接続数との関係
nginxはfpmをupstreamとして扱う。 Railsとかのプロセスとほとんど考え方は一緒。
nginxで受けてまだfpmに空きがなければ、あくまで待つっぽい。多分キュー。
これによって上記でApacheだと〜って問題がなくなってるし、メモリリークがあっても500回とか処理したらプロセス捨てて別なプロセスに任せるみたいな強引なやり口で、メモリ問題が解決出来る。たいへん賢い。
php.iniでのメモリ上限
/etc/php7.d/php.ini
# 1プロセスあたりの上限を128Mとする
memory_limit = 128M
fpmの同時処理数の設定
/etc/php7-fpm.d/www.conf
# ワーカーあたりの最大同時処理数っぽい。kusanagiのデフォは50っぽい。
pm.max_children = 50
# プロセスを自動で立ち上げといてくれるらしい
pm.min_spare_servers
pm.max_spare_servers
# ↑の初期値。未指定でデフォにしてもよさげ
pm.start_servers
ここから、理論上PHPだけで128Mx50 = 6.25G使う可能性があることが分かる。
ただし、現実的にはそれを食い尽くす事はないだろうし、スワップで間に合う範囲でもあるから、妥当な数字に思える。
逆に言えば、1GBだと、OS自体やnginx自体などのフットプリント的なRAM容量を考慮して max_children=10 にするのが安定しそう。
実際落ちてたのが直った
実際、apache bench alternativeなboomってコマンドで以下のような事をして虐めると、あっという間に悪名高い「データベース接続エラー」になってたけど、max_childrenを10にしたら起きなくなった。時間はかかるけど。
boom -a staging:staging -n 100 -c 50 http://staging.example.com/hoge-fuga-piyo/
kusanagiはDB落ちると復活しないっぽい
monitの仕事がダメなので、DBサーバーが落ちると勝手には復帰しないみたい。
monitの監視時間の問題かも。
結論
- fpmのチューニングしたいときは /etc/php7-fpm.d/www.conf みたいなファイルの pm オプション群で指定できる
- KUSANAGIは推奨環境を守れば速い（たぶん）ので、ちゃんと守ろう