長々と苦しめられてきたphp-fpmのメモリリーク疑惑。未だ原因はわからないんですが、なんとか丸1日サーバを落ち着かせることに成功したのでシェアします。
原因不明のphp-fpmのフルスロットル化＋mysqlレスポンス低下
これまでの奮闘記はこちら。
https://freesim.tokyo/wordpress/memory-leak-php-fpm-config/
結論から言えば、このphp-fpmのスロットが全部埋まってmysqlのレスポンスが低下して・・という根本的な原因は分からないまま。
けれどサーバの挙動を都度都度ウォッチした結果、以下のようなフローでサーバレスポンスが低下することは確定です。
php-fpmのプロセス数が上限値まで一気に上がる
↓
mysqlのクエリー応答時間が低下
↓
サーバのLoad Timeも上がる
↓
アクセスが溜まるのでさらに悪化（ふりだしへ戻る）
最初はmysql(mariadb)側だと思ってたんですがね・・・。プロセスが10本以上上がってるのにメモリ専有がそれぞれ10%とかなので「これに違いない！」と思っていたのですが・・・
因果関係で見るとphp-fpm側が先にいっぱいいっぱいになっているようです。
muninが入っているので以下でいま時点の情報が見れます。
munin-run phpfpm_status
で、結果は今だとこうなります。
idle.value 13
active.value 2
total.value 15
これが挙動がおかしい時は・・・
idle.value 1
active.value 14
total.value 15
とか、さらにおかしければ
idle.value 0
active.value 2
total.value 2
とかになってる。static（プロセス数固定）でやってても上限が勝手に変わってたり。で、結論この文字列を取り込んでactive.value / total.value > 0.8とかになったらsystemctrl restart php-fpm.serviceするようにしています。
それをcronで5分ごとに動かせばOK。
muninグラフはこう変わりました
muninのグラフはこんな風に変わりました。
php-fpm
問題児のphp-fpm。たまに上限（オレンジ）が下がっていますが、多分cronで再起動したのとmuninのチェックがかぶったからかな？と思っています。
とりあえず安定。
mysql
mysqlはこちらです。こちらも荒ぶることなく動いてますね。
月表示にするとこんな感じ。何度も一時的に遅くなりながら、徐々にその時間が長くなっていってるのがわかります。
このままだとどうなったことやら・・・。
Load Average
サーバ負荷のLoad averageのグラフ。こちらも問題なく。
ずーっと0.3くらいで動いています。
結局安定稼働させるためのパッチを自分で走らせる、というパッチ的なアプローチでしたが、とりあえずこれで収まったので一件落着、としましょう。
