ここのところKUSANAGIが頻繁に落ちるようになりました。
管理画面で少し操作するだけで落ちてしまいます。
何もしなくても落ちてしまいます。
KUSANAGI9にしたのが悪いのか。
WEXALの適用サイト数を増やしたのが悪いのか。
それとも他の要因なのか。
何かわかりませんけど、
とにかく対処してみることにしました
【2026年6月19日追記】
その後、WEXAL停止・構成変更・各種最適化を行ったため、本記事で紹介している数値は現在使用していません。
本記事は「KUSANAGIでサーバーダウンが発生した際に、どのような手順で原因を調査したか」という運用記録として残しています。
sar や top を用いた調査手順そのものは現在でも有効です。
確定している要因から対処する
サーバーが落ちる要因として一つは確定しています。
バックアッププラグインBackwup。
KUSANAGI8の時から、処理が重いせいで作業途中に一度は落ちてました。
夜中ですし、最近はサイト運営どうでもよかったので放置してました。
ただKUSANAGI9へ移行して新たな環境になり。
いい機会として対処することにしました。
バックアップファイルを減らして作業量を減らすという原始的な方法で対処。
寝てる間にcronで３サイト分のバックアップを実行させてみたところ、無事に作業完了。
死活監視のサーバーダウンメールも届いてませんでした。
この問題は一件落着です。
【2026年6月19日追記】
現在はBackwupの利用そのものを止めています。
プラグインのアップデートにより、大幅な仕様変更があったためです。
不明な要因を探る
実のところ、前項の問題で終わったと思っていました。
しかし今朝、
サーバーが落ちる！
バックアップと関係無く落ちる！
３時間で３回も落ちた！
何もしてないのに。
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を止めて手動チューニングに戻すことも考えています。
【2026年6月19日追記】
現在はWEXALの利用を止めています。
当時のトラブルの原因は確定しないままですが、サーバーは安定しています。
VPSは、もう「黒い画面」だけじゃない。
「VPSは難しそう」と諦めていませんか？ ConoHaのKUSANAGIなら、ブラウザ上の管理画面（KUSANAGI Manager）で、ドメイン設定からSSL発行まで直感的に操作可能です。
コマンド操作なしで世界最速級の環境を構築できる、今の時代の初心者にとっての最適解。私が長年愛用している理由がここにあります。
※当サイト経由で新規申し込みいただくと、特典として1000円分のクーポンをもらえます。