ディスク容量：どこへ消えるのか

空き容量の不足は、一見すると別の障害に見える形でサービスを停止させます。データベースが書き込めなくなり、サイトがエラーを返し、コンテナが再起動を繰り返します。VDS のディスクはエントリーティアで 40 GB、最上位ティアで 250 GB で、ほぼ必ず同じようなものが容量を圧迫していきます。

最初に実行するコマンド

df -h
df -i
sudo du -x -h -d1 / | sort -h | tail -15

df -i を省略しないでください。空き容量はあっても inode が不足することがあります。その場合、数ギガバイトの空きがあるのに「ディスクが一杯です」という状態になります。原因はたいてい、何百万もの小さなキャッシュファイルです。

次に、最も大きなディレクトリを掘り下げます。

sudo du -x -h -d1 /var | sort -h | tail
sudo du -x -h -d1 /var/lib | sort -h | tail

-x フラグはカウントを単一のファイルシステム内に保ち、マウントされたディレクトリには入り込みません。

よくある原因

削除したのに容量を占有し続けるファイル

よくある難問です。du は 5 GB と表示するのに、df は 30 GB 使用と表示します。これは、ファイルは削除されたものの、プロセスがまだファイルを開いたまま保持しており、再起動するまで容量が解放されないことを意味します。

sudo lsof +L1 | head -20

出力にはプロセスとサイズが表示されます。解決策は原因のプロセスを再起動することです。

sudo systemctl restart <service>
docker compose restart <service>

使用中のログファイルを rm で削除して空き容量を確保しないでください。正しい方法は切り詰めることです。sudo truncate -s 0 /var/log/big.log。削除すると容量が占有されたままになり、さらにログも失います。

コントロールパネルの使用量リング

「概要」タブにはディスク使用量のリングがあります。これはゲストエージェント qemu-guest-agent を介して計算されます。エージェントが削除されているか実行されていない場合、データは更新されません。パネルにはインストールコマンドが表示されます。マシン内で確認するには、次のコマンドを実行します。

systemctl status qemu-guest-agent

エージェントの測定値と df -h は一致するはずです。相違がある場合、ほとんどの場合は別途マウントされたパーティションで容量が使われています。パーティションとファイルシステムを参照してください。

予防

クリーンアップとアラートを含むスケジュールタスクを設定します。

#!/bin/bash
USED=$(df --output=pcent / | tail -1 | tr -dc '0-9')
if [ "$USED" -gt 85 ]; then
  journalctl --vacuum-size=200M
  apt clean
  docker image prune -f
  echo "Disk is ${USED}% full" | mail -s "VDS: low disk space" you@example.com
fi

85% のしきい値があれば、対応する余裕が生まれます。100% を待つことはできません。ディスクが一杯になると、何が起きたかをログに書き込むことすらできないサービスもあります。

まったく空き容量がない場合

1. 手早い対処で数ギガバイトを解放します。journalctl --vacuum-size=100M、apt clean、docker builder prune -f。
2. 上記のコマンドで本当の原因を突き止めます。そうしなければ、1 週間で同じことが繰り返されます。
3. データが本当に増えている場合は、より上位のティアへ移行してディスクを増設する必要があります。ダウングレードは利用できません。ディスクは縮小できないためです。