Linux インスタンスにおけるディスク容量不足問題の解決 - Elastic Compute Service

Linux インスタンスでアプリケーションとサービスが継続的に実行されると、ログ、キャッシュ、ビジネスデータが時間とともに蓄積され、利用可能なディスク容量を徐々に消費します。ディスク容量が不足すると、新しいデータを書き込むことができなくなり、サービスの停止や異常な動作が直接引き起こされます。

症状

Linux インスタンスでファイルを作成したり、アプリケーションを実行したりすると、No space left on device というエラーメッセージが表示されます。これは、ストレージリソースが枯渇していることを示します。

診断と解決策

重要

変更を加える前に、手動スナップショットを作成してデータをバックアップし、ビジネスに影響を与える可能性のある偶発的なデータ損失を防いでください。

シナリオ 1：ディスク容量の枯渇

ディスク使用状況の確認

sudo df -h を実行すると、各マウントポイントのディスク使用量が表示されます。Use% の値が 100% の場合、対応する領域がいっぱいになっています。
不要なファイルまたはフォルダーのクリーンアップ

指定したディレクトリ内のファイルとサブフォルダーのサイズを確認するには、sudo du -sh <folder name>/* を使用します。必要に応じて、ディレクトリに移動してこのコマンドをレベルごとに繰り返し、サイズの大きい項目を特定します。

たとえば、sudo du -sh /mnt/* を使用して、/mnt ディレクトリ配下のファイルとサブフォルダーが使用するディスク容量を確認します。
クリーンアップ後も容量が不足している場合は、ディスクのスケールアウトを行います。

シナリオ 2: Inode リソースの枯渇

各ファイルは 1 つの inode を消費します。ディスクに多数の小さいファイルが含まれている場合、ディスク容量が残っていても inode が枯渇し、新しいファイルを作成できなくなることがあります。

inode 使用状況の確認

sudo df -i を実行します。IUse% の値が 100% に達した場合、inode リソースは枯渇しています。
不要なファイルまたはフォルダーのクリーンアップ

sudo du -sh --inodes <folder name>/* を使用すると、指定されたディレクトリ内のファイルとサブフォルダーが使用する inode 数を確認できます。必要に応じて、ディレクトリに移動し、このコマンドを再帰的に使用して inode を大量に使用している場所を特定します。

たとえば、/mnt ディレクトリ内のファイルとサブディレクトリが使用する inode 数を確認するには、sudo du -sh --inodes /mnt/* を使用します。
クリーンアップ後も inode 数が不足している場合は、ディスクのスケールアウトを行います。

シナリオ 3：削除されたファイルが依然として容量を占有している

ファイルが削除された後でも、プロセスがまだそのファイルを使用している (つまり、開いているファイルハンドルを保持している) 場合、システムはそのディスク容量を解放しません。容量は、プロセスが終了するか、ファイルを明示的に閉じたときにのみ解放されます。

lsof ツールをインストールします。

削除されたが、まだ領域を確保しているファイルは、dfまたはduでは確認できません。lsof ツールを使用して、それらを一覧表示します。
Alibaba Cloud Linux、CentOS
```
sudo yum install -y lsof
```
Debian、Ubuntu
```
sudo apt install -y lsof
```

削除されたファイルが保持しているストレージ容量の表示

sudo lsof | grep '(deleted)' | sort -k7 -rn | more

出力の 7 列目は、ファイルサイズをバイト単位で示します。これらの値を合計して、解放されていない合計容量を計算します。

tail      619544                        root    3r   REG    253,1   50000000    136507 /home/test_file (deleted)
aliyun-se 347980                        root    7uW  REG    253,1          0    262160 /tmp/AliyunAssistClientSingleLock.lock (deleted)
aliyun-se 347980 347997 aliyun-se       root    7uW  REG    253,1          0    262160 /tmp/AliyunAssistClientSingleLock.lock (deleted)
aliyun-se 347980 347996 aliyun-se       root    7uW  REG    253,1          0    262160 /tmp/AliyunAssistClientSingleLock.lock (deleted)
aliyun-se 347980 347995 aliyun-se       root    7uW  REG    253,1          0    262160 /tmp/AliyunAssistClientSingleLock.lock (deleted)
aliyun-se 347980 347994 aliyun-se       root    7uW  REG    253,1          0    262160 /tmp/AliyunAssistClientSingleLock.lock (deleted)
aliyun-se 347980 347983 aliyun-se       root    7uW  REG    253,1          0    262160 /tmp/AliyunAssistClientSingleLock.lock (deleted)
aliyun-se 347980 347982 aliyun-se       root    7uW  REG    253,1          0    262160 /tmp/AliyunAssistClientSingleLock.lock (deleted)
aliyun-se 347980 347981 aliyun-se       root    7uW  REG    253,1          0    262160 /tmp/AliyunAssistClientSingleLock.lock (deleted)

プロセス名と PID の記録

sudo lsof | grep delete を実行し、COMMAND フィールドと PID フィールドを確認してプロセス名とプロセス ID を特定します。
関連サービスの再起動または停止

sudo ps -ef | grep <PID> を実行してプロセスの目的を確認し、影響を評価してからサービスを再起動または停止します。

重要
サービスの再起動または停止は、ビジネスに影響を与える可能性があります。慎重に評価し、適切なメンテナンス期間中にこの操作を実行してください。

シナリオ 4：マウントポイントのオーバーレイ

空ではないディレクトリが別のデバイスのマウントポイントとして使用されると、その既存のコンテンツは隠されます。しかし、そのディレクトリをすでに開いているプロセスは、基になる領域に引き続き書き込むことができます。この「隠された」領域の消費は df コマンドでは確認できず、予期せずディスク領域を使い果たす可能性があります。

重複フォルダーに関する情報の表示

sudo lsblk を実行し、MOUNTPOINT 列で重複するディレクトリ名を確認します。

sudo lsblk

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda    253:0    0   40G  0 disk 
├─vda1 253:1    0    2M  0 part 
├─vda2 253:2    0  200M  0 part /boot/efi
└─vda3 253:3    0 39.8G  0 part /
vdb    253:16   0   40G  0 disk 
└─vdb1 253:17   0   40G  0 part /mnt
vdc    253:32   0   40G  0 disk 
└─vdc1 253:33   0   40G  0 part /mnt

この例では、パーティション vdb1 と vdc1 の両方が /mnt にマウントされており、マウントポイントのオーバーレイのリスクを示しています。

ファイルシステムのアンマウント

重要
ファイルシステムをアンマウントすると、そのパスに依存するサービスが中断される可能性があります。リスクを評価し、適切な時期にこの操作を実行してください。

前の手順から <複製マウントディレクトリ> を取得できます。
```
sudo umount <重複マウントディレクトリ>
```
この例では、/mnt は重複マウントディレクトリです。sudo umount /mnt を実行すると、最後にマウントされたデバイスである vdc1 がアンマウントされます。

オーバーレイされたマウントポイントのデバイス名の特定

sudo df -h を実行して、現在アクティブなマウントポイントに関連付けられているデバイス名を特定します。

sudo df -h

Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        3.7G     0  3.7G   0% /dev
tmpfs           3.7G     0  3.7G   0% /dev/shm
tmpfs           3.7G  524K  3.7G   1% /run
tmpfs           3.7G     0  3.7G   0% /sys/fs/cgroup
/dev/vda3        40G  4.5G   33G  12% /
/dev/vda2       200M  5.8M  194M   3% /boot/efi
/dev/vdb1        40G   40G     0  100% /mnt
tmpfs           747M     0  747M   0% /run/user/0

この例では、現在 /mnt にマウントされているパーティションは vdb1 です。したがって、オーバーレイマウントポイントのデバイス名は vdb1 です。

ディスク容量不足問題の解決
1. オーバーレイされた領域にある不要なファイルまたはフォルダーをクリーンアップします。
  
  この例では、vdb1 によってマウントされた /mnt ディレクトリをクリーンアップします。
2. クリーンアップ後も容量が不足している場合は、ディスクのスケールアウトを行い、別の空のディレクトリにマウントします。
  
  この例では、スケールアウトする対象デバイスは vdb1 です。

重要

複数のデバイスを同じディレクトリにマウントしないでください。

複数のデバイスを同じディレクトリにマウントすると、最初にマウントされたデバイスの容量が隠され、データが誤ったデバイスに書き込まれる可能性があります。常に異なるデバイスを別々の空のディレクトリにマウントしてください。

シナリオ 5：Docker 関連ファイルが多くの容量を消費している

Docker は、操作中に多くの中間イメージ、停止したコンテナ、およびビルドキャッシュを生成します。時間が経つにつれて、これらが蓄積され、ディスク容量を消費します。

Docker のディスク容量使用状況の確認

sudo df -h を実行します。Filesystem のタイプが overlay で、その Use% が 100% に達した場合、Docker ストレージは満杯です。
Docker のリソース使用状況の評価

sudo docker system df を実行し、Size と RECLAIMABLE の各フィールドを確認して、スペース消費量を把握します。
```
sudo docker system df
```
```
TYPE            TOTAL      ACTIVE     SIZE       RECLAIMABLE
Images          21         9          13.94GB    10.66GB (76%)
Containers      9          5          30.09MB    0B (0%)
Local volumes   6          6          259.9MB    0B (0%)
Build Cache     0          0          0B         0B
```
この例では、Docker イメージは 13.94 GB を占有しており、そのうち 10.66 GB は解放可能です。未使用のイメージを優先的にクリーンアップすることをお勧めします。
不要なファイルをクリーンアップします。

Docker ファイルをクリーンアップできない場合は、シナリオ 1：ディスク容量の枯渇の手順に従ってください。
- すべての停止したコンテナを削除するには、sudo docker container prune を実行します。
- すべてのダングリングイメージ (タグなしイメージ) を削除するには、 sudo docker image prune を実行します。
- 未使用のビルドキャッシュを削除するには、sudo docker builder prune を実行します。

シナリオ 6：inotify watch の上限に到達

sudo tail -f のようなコマンドを実行すると、tail: cannot watch '...': No space left on device というエラーが表示されることがあります。これはディスク容量が不足しているのではなく、ファイルやディレクトリの変更を監視するために使用される inotify watch の数がシステムの上限に達したことを意味します。この上限を引き上げる必要があります。

現在の inotify watch の上限の確認

sudo cat /proc/sys/fs/inotify/max_user_watches を実行して、inotify watches の現在の上限値を確認します。
inotify watch の上限を増やす

この上限値を上げるとメモリ使用量が増加します。変更する前に慎重に評価してください。一般的に、 <new limit> は 524288 を超えないようにしてください。
```
sudo sh -c "echo fs.inotify.max_user_watches=<新しい上限値> >> /etc/sysctl.conf"
```
新しい設定の読み込み

sudo sysctl --system を実行して、更新された設定を適用します。
結果の確認

sudo cat /proc/sys/fs/inotify/max_user_watches をもう一度実行し、inotify watches の制限値が期待どおりに更新されたことを確認します。

Elastic Compute Service:Linux インスタンスにおけるディスク容量不足問題の解決

症状