障害対応 inodeの枯渇

障害対応

そろそろ、本気でザビックスの導入を検討しているsaburoです。

先日、TuList にて数日にわたる障害を起こしてしまいまして、反省を込めて記事にします。

マネタイズができていないこともあり、監視も入れておらずしばらく放置となってしまったのが、数日間のサービス停止となってしまった大きな要因です。

概要

簡単な概要はこんな感じ

  1. サイトトップの更新が11月15日で止まっていることに気がつく
  2. 簡単に調査するも原因がわからず、conohaに問い合わせ
  3. conohaが調査をしてくれたが、解決策見つからず
  4. ふと、inodeが原因かも・・・と思い大量のキャッシュを削除
  5. 無事解決

障害調査

15日で更新が停止している事実を知ったのは22日、この時すでに数日が経っており監視の重要性を再認識・・・マジで入れよう。

で、大量のデータを扱っているので、HDDを圧迫することはよくあ流のでひとまずdfコマンドでHDDの容量をチェック。

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           498M     0  498M   0% /dev/shm

あれ、デバイスが1つしかマウントされていない???
しかも、Sizeが498M?

だけど、/var/www/ 配下のファイルに対してはアクセスができるという。

mount -a を実行してみるも、解決されず・・・

conohaの回答

conohaの回答も mount -a を実行してみてくれとのこと。

/var/www/にアクセスできるため、マウント自体はされているはずだけど、とりあえず実行してその後の様子を送り、引き続き助言が欲しい旨を送る。

解決はしなかったものの、以前にもconohaのサポートにはお世話になっているけど、対応が丁寧で本当に感謝!

解決編

おそらく、inodeが枯渇していたのが原因と思われる。

TuListではレスポンス対策として、1動画に対して1キャッシュファイルを生成している。
そのため、しばらく放置しておくとあっという間にファイル数が増えてしまうのです。

とはいえ、2ヶ月くらい前にサーバー移転したばかりだったので、まさかとは思っており気がつくのが遅れてしまいました。

このキャッシュファイルは動画にアクセスされた際に再生成されるので、消してしまっても問題がないので、一旦大量のファイルを削除。

inodeの確認をするには df -i とオプションをつけて実行。

$ df -i
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/vda2      3276800 219882 3056918    7% /
tmpfs           127476      1  127475    1% /dev/shm

無事に、マウントされていることとinodeにあきがあることを確認。

念の為Webサーバーも再起動して無事にサービスも復旧しました。

補足

inodeとは

inodeとはLinuxのファイルシステム上で使われるヘッダーを扱う情報のこと。

ファイル・ディレクトリごとにinodeが利用され、前述した復旧後のdf -i の実行結果を見る限り、300万ノードほど利用可能なことがわかる。

・・・ってことは300万ノードを使い切っていたってことだよね。
(動画情報が1000万以上あるので、使い切る可能性は十分にある)

シェアする

  • このエントリーをはてなブックマークに追加

フォローする