ここのところKUSANAGIが頻繁に落ちるようになりました。
管理画面で少し操作するだけで落ちてしまいます。
何もしなくても落ちてしまいます。
KUSANAGI9にしたのが悪いのか。
WEXALの適用サイト数を増やしたのが悪いのか。
それとも他の要因なのか。
何かわかりませんけど、とにかく対処してみることにしました。
確定している要因から対処する
サーバーが落ちる要因として一つは確定しています。
バックアッププラグインBackwup。
KUSANAGI8の時から、処理が重いせいで作業途中に一度は落ちてました。
夜中ですし、最近はサイト運営どうでもよかったので放置してました。
ただKUSANAGI9へ移行して新たな環境になり。
いい機会として対処することにしました。
バックアップファイルを減らして作業量を減らすという原始的な方法で対処。
寝てる間にcronで３サイト分のバックアップを実行させてみたところ、無事に作業完了。
死活監視のサーバーダウンメールも届いてませんでした。
この問題は一件落着です。
不明な要因を探る
実のところ、前項の問題で終わったと思っていました。
しかし今朝、
サーバーが落ちる！
バックアップと関係無く落ちる！
３時間で３回も落ちた！
何もしてないのに。
KUSANAGI8の時はこんなことなかったんです。
変わったところといえば、
- 移行する際にサイト分割して２サイトから３サイトにした。
- WEXALを１サイトから３サイト適用に増やした。
しかしサイトは元々あったのを分割しただけ。
WEXALもクロール＆戦略生成の際に落ちるのは仕方ないとして、通常時はリソース消費少ない。
そこまで大きく変わると思えないんだけど……。
ただ、そういえば、
移行してから管理画面がやたら重いし、ちょっとした弾みで500エラーやデータベース接続エラー出るんだよな
根本的に問題ありそうなので調べてみることにしました。
ConoHa VPSのリソースモニターで簡易的に調べる
ConoHa VPSにはリソースモニターがあり、簡易的・視覚的に利用状況を調べることができます。
覗いてみてびっくり。
なんじゃ、こりゃ！
CPU。
ディスクIO。
突如として利用量が跳ね上がっています。
この跳ね上がっているときにサーバーが落ちているわけですが……。
いったいどうして？
アクセスログをチェックする
まさかDDoS攻撃？
念のため全てのサイトの本日のアクセスログをチェック。
少なくとも２回目３回目のダウンは関係なさそう。
というか、もしそうだったら、
やれるだけの対策はほとんどやってるのでお手上げ
やってないのはREST APIの停止。
プラグイン動かす点で不便なので、きっちり動作検証する時間があるときやろうと思います。
リソース利用状況を詳細に調べる
sarコマンドでリソース利用状況を調べます。
KUSANAGIには予めインストールされています。
# sar
サーバーダウンしたところで、突発的に%systemが100近くまで跳ね上がっています。
しかしその理由については、
わからない、見当すらつかない
私、完全なる素人ですんで。
わかるくらいならエンジニアとして働いてます。
なので、とりあえず放置します。
続けてCPUとメモリの状況を俯瞰。
#top
平常時でもメモリ使用量が高く、swapまで大量に使ってしまっている。
これは何かあれば、すぐにswapまで食いつぶしてしまって落ちるであろうことは想像つきます。
まずはこの現象からなんとかしましょう
他に似た人がいないか調べてみる。
どっちにしても重いのは間違いないので対処することにします。
KUSANAGI 落ちるのワードで片っ端から調べてみました。
すると……いました。
PHPとデータベースが問題、ふんふん。
少なくともデータベースは私の環境でも言えそう。
ざっと読んだ後、冒頭に書かれていた記述に気づきます。
kusanagi configure
を実行すればいいと。このコマンドは環境に最適な設定をするようですね？
※現在はcofigureコマンドありません。dbinitとphpコマンドに変わっています。
これって逆じゃなかったっけ？
configureするとKUSANAGIデフォルトの数字に戻ります。
しかし低スペックVPSでデフォルトだとサーバーに負担かかるから調整した方がよかったような。
それで私は自分でやってconfigureしないよう気をつけてたような……ん？
どうして著者はそんなことしたんだ？
困ったことは大抵備忘録にして記事にしてますので読み返してみました。
過去の行動を思い出した
過去にデータベースの数値を調整した記事はこちらでした。
メモリ不足によるスワップ頻発で重くなったのをMySQL（MariaDB）の設定を変えることで対処しました。
とりあえず少しはマシになり、いつの間にか解決してしまってました。
そういえば……
2GBプランに変えた後でkusanagi configureしたっけ？
configureさえしなければ設定した数字がそのまま残ります。
1GBプランの設定を更に軽くして2GBで使ってたわけですからエラーも起こりづらいはずです。
KUSANAGI8の時のサーバーは削除してしまったので確認はできませんが。
KUSANAGI9にアップグレードする際は自分で設定した数値がリセットされます。
もしかしたらそのせいで重くなってたのかも？
昔の数字に戻して試してみましょうか
MySQL（MariaDB）をチューニングする
KUSANAGI9のデフォルトは、
query_cache_size = 128M innodb_buffer_pool_size = 384M
2GBプランでも、過去の1GBプランデフォルトと同じでした。
これを過去に設定していた数字に変更します。
ファイルは次の場所にあります。
/etc/my.cnf.d/server.cof
該当箇所を次の数字に変更します。
query_cache_size = 64M innodb_buffer_pool_size = 128M
php-fpmをチューニングする
php-fpmも調整しておきます。
次のファイルを編集します。
/etc/opt/kusanagi/php-fpm.d/www.conf
次の数値を変更します。
pm.max_children = 15
デフォルトは50です。
参考記事（文中リンク以外）
php-fpmとRAMのお勉強メモ。KUSANAGIで試した。
KUSANAGI にインストールされている保守向けコマンド（top編）
まとめ
１日が経過。
ひとまず管理画面重いのは直りました。
これまで「落ちる！」と思った状況でも持ちこたえるようになりました。
ただ通常時でもスワップをかなり食ってるので不安なのは変わりません。
まあ、とりあえずこれで様子見てみる
このまま落ちないといいわね……
場合によってはWEXALを止めて手動チューニングに戻すことも考えています。
