容量切れは、悪意がまったく関与しないままサーバーが止まる最も多い原因です。サイトは 500 を返し、データベースは書けず、メールは出て行かない——その一方で df -h は数ギガバイトの空きを報告しています。それが起こる三つの場合と、SMART について知っておく価値のあることを見ていきましょう。

第一の場合：inode が尽きた

ファイルシステムには有限の資源が二つあります。中身のための場所と、ファイルについての記録です。二つ目は一つ目とは独立に尽きます。

df -h
df -i

二つ目のコマンドで IUse% が 100 なら、問題は inode です。場所はあるのに、空のものすら一つのファイルも作れません。

犯人はいつも同じです。何百万もの小さなファイル。ガベージコレクションが壊れた /var/lib/php/sessions の PHP セッション。決して消されないアプリケーションのキャッシュ。詰まったメールのキュー。サムネイルのディレクトリ。こうやって探せます。

sudo find / -xdev -type f -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -20

このコマンドはファイル数の多いディレクトリを並べます。大きなシステムでは数分かかります——それは普通のことです。

第二の場合：ファイルは消したのに容量が戻らない

さらに厄介な状況です。誰かが膨らんだログを rm で消したのに、そこへ書いているプロセスがまだ開いたまま保持している。ファイルはもうディレクトリに無く、容量は占有されたままで、そのプロセスが再起動されるまでそのままです。

sudo lsof +L1

このコマンドは、ファイルシステム上のリンク数がゼロなのに、まだプロセスに保持されているファイルを示します。治し方はそのプロセスの再起動か穏やかな読み直しであって、「ギガバイトはどこへ消えた」の捜索ではありません。

ここから規則が出ます。膨らんだログは削除するのではなく空に切り詰めます。そうすれば開いているディスクリプタは使えるままです。

sudo truncate -s 0 /var/log/huge.log

そしてその直後にローテーションを設定してください——でないと一週間で同じことが繰り返されます。

第三の場合：ログが食べた

容量がどこへ行ったかは、階層を下りながら見れば分かります。

sudo du -x -h --max-depth=1 / | sort -h
sudo du -x -h --max-depth=1 /var | sort -h

-x フラグは他のファイルシステムへさまよい出るのを防ぎます。これが無いと集計は /proc やネットワークマウントへ這い込みます。これらはすべて ncdu があればそちらのほうが快適です。

おなじみの大食らい：

  • journald。コマンド一つで片づきます：journalctl --disk-usage。/etc/systemd/journald.conf の SystemMaxUse=500M の行で上限を決め、journalctl --vacuum-size=200M で一度掃除します；
  • セキュリティツールのログ。既定設定の Suricata は三十種類のイベントを書き、自分のためのローテーションは設定しません——実際のサーバーでは二日で 15 GB を作りました。audit.log や nginx のデバッグログでも同じことが起こります；
  • バックアップ。同じディスクに書かれ、決して消されないもの；
  • apt のキャッシュ——apt clean が時おり数ギガバイトを返してくれます。

/boot について一言

古いカーネルで埋まっていく小さなパーティションです。それ自体がサイトを落とすことはありませんが、更新を完全に止めます。新しいカーネルが入らず、パッケージのキューがまるごとその後ろで詰まります。治療は apt autoremove --purge、予防は自動更新の設定で未使用カーネルの自動削除を有効にすることです。

SMART：どの属性が重要か

先に断っておくと、仮想サーバーでは SMART はたいてい使えません——ディスクは仮想であり、その下の物理ディスクは見えません。これは不具合ではなく、単にデータが無いのです。以下はすべて専用サーバーと自分のハードウェアについての話です。

sudo smartctl -a /dev/sda

SMART overall-health self-assessment test result: PASSED の行は安心する理由になりません。ドライブが死ぬ直前まで実質的に緑のままだからです。見るべきは具体的なカウンタです。

  • 5、Reallocated_Sector_Ct——代替処理されたセクタ。ゼロでなければドライブはすでに劣化中であり、時間とともに増えるなら先延ばしせず交換を；
  • 197、Current_Pending_Sector——読めずに判定待ちのセクタ。この中で最も不穏なものです。たいていデータの一部がすでに復旧不能であることを意味します；
  • 198、Offline_Uncorrectable——同じもので、検査によって確認済み；
  • SSD：Percentage Used / Media_Wearout_Indicator——消費した書き込み寿命。予測可能な数字であり、交換を計画する基準になります。

一方で温度と通電時間はそれ自体では何も語りません。五年動いていてエラーカウンタがゼロのドライブは、属性 197 に 1 のある新品より頼りになります。

見張ることの意味

ここまでのすべては、すでに起きたことへの反応です。ところが埋まっていくディスクも SSD の摩耗も、どちらもゆっくりした完全に予測可能な過程です。二週間分の占有のグラフは、容量が尽きる日付をはるか前に示してくれます。「サイトが午前三時から落ちている」と「木曜にログを片づける必要がある」の違いは、その数字が目の前にあるかどうかだけです。組み上がった状態がどう見えるかは下のデモページで。