Elastic Compute Service:Linux インスタンスにおける「No space left on device」問題の解決策

1. ディスク領域の枯渇

1. ディスク使用率を確認します。

   sudo df -h を実行し、マウントポイントごとのディスク使用率を確認します。Use% が 100% の領域が枯渇状態です。

2. 不要なファイルやディレクトリをクリーンアップします。

   sudo du -sh <directory_name>/* コマンドで特定のディレクトリ内のファイルとサブディレクトリのサイズを確認します。必要に応じて、サブディレクトリに移り、階層ごとの使用量を確認してください。

   例：sudo du -sh /mnt/* を実行して、/mnt ディレクトリ内のファイルとサブディレクトリのサイズを確認します。

3. クリーンアップ後もディスク領域が不足している場合は、ディスクのサイズを変更できます。

2. Inode リソースの枯渇

各ファイルは 1 つの inode を占有します。小さなファイルが大量に存在するディスクでは、ディスク領域に空きがあっても Inode が枯渇すると、新しいファイルを作成できなくなる場合があります。

1. inode の使用率を確認します。

   sudo df -i コマンドを実行します。IUse% 列が 100% の場合、すべての inode リソースが枯渇しています。

2. 不要なファイルやディレクトリをクリーンアップします。

   sudo du -sh --inodes <folder_name>/* コマンドを実行して、特定のディレクトリ内のファイルとサブディレクトリが使用している inode の数を確認します。必要に応じて、サブディレクトリに移り、このコマンドで各階層の inode 使用状況を確認できます。

   例：sudo du -sh --inodes /mnt/* を実行して、/mnt ディレクトリ内のファイルとサブディレクトリが使用している inode の数を確認します。

3. クリーンアップ後も inode の数が不足している場合は、ディスクのサイズを変更できます。

3. 使用中の削除済みファイルによるディスク領域の占有

ファイルが削除されても、プロセスがそのファイルを使用している (つまり、ファイル記述子を保持している) 限り、ファイルが占有していたディスク領域は解放されません。ディスク領域は、プロセスが終了するかファイルを閉じた後にのみ解放されます。

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

   df や du コマンドでは、領域を占有し続けている削除済みファイルを特定できません。このようなファイルは、lsof ツールで一覧表示できます。

   Alibaba Cloud Linux および CentOS

   sudo yum install -y lsof

   Debian および Ubuntu

   sudo apt install -y lsof

2. 削除済みファイルが保持しているストレージ領域を確認します。

   sudo lsof | grep delete | sort -k7 -rn | more

   出力の 7 列目はファイルサイズ (単位：バイト) を示します。これらの値を合計することで、未解放の領域の総量を算出できます。

3. プロセス名と PID を控えます。

   sudo lsof | grep delete を実行し、COMMAND 列と PID 列のプロセス名と PID を控えてください。

4. 関連サービスを再起動または停止します。

   sudo ps -ef | grep <PID> を実行してプロセスの役割を確認します。その後、影響を評価した上でサービスを再起動または停止してください。

   重要

   サービスの再起動や停止は業務に影響を及ぼす可能性があります。 事前に影響を評価し、適切なメンテナンスウィンドウ内で実施してください。

4. 別のマウントによるマウントポイントの隠蔽

デバイスを空でないディレクトリにマウントすると、そのディレクトリに元々存在していた内容は不可視になります。 ただし、そのディレクトリをすでに開いていたプロセスは引き続きデータを書き込めます。 この「隠れた」領域の消費は df コマンドでは検出できず、予期せぬディスク領域の枯渇につながる場合があります。

1. 重複するマウントポイントを確認します。

   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 にマウントされており、マウントポイントが隠されるリスクがあります。

2. ファイルシステムをアンマウントします。

   重要

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

   <duplicate_mount_point> は前の手順で取得できます。

   sudo umount <duplicate_mount_point>

   この例では、/mnt が重複するマウントポイントです。sudo umount /mnt を実行すると、最後にマウントされたデバイス vdc1 がアンマウントされます。

3. 下層のマウントポイントのデバイスを特定します。

   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 にマウントされているデバイスは /dev/vdb1 です。

4. ディスク領域不足の問題を解決します。

   1. 以前に隠されていた領域から不要なファイルやディレクトリをクリーンアップします。

      この例では、vdb1 からマウントされた /mnt ディレクトリをクリーンアップする必要があります。

   2. クリーンアップ後も領域が不足している場合は、ディスクのサイズを変更し、別の空のディレクトリにマウントします。

      この例では、サイズ変更の対象となるデバイスは vdb1 です。

5. Docker リソースによる大量のディスク領域消費

Docker の操作により、多くの中間イメージ、停止したコンテナー、ビルドキャッシュが生成されることがあります。時間の経過とともに、これらのオブジェクトが蓄積し、ディスク容量を消費します。

1. Docker ファイルのディスク容量使用率を確認します。

   sudo df -h コマンドを実行します。Filesystem が overlay となっている項目で Use% が 100% に達している場合、Docker が領域を消費していることを示します。

2. ディスク領域を使用している 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 が再利用可能です。未使用のイメージのクリーンアップを優先することを推奨します。

3. 不要なファイルをクリーンアップします。

   Docker ファイルをクリーンアップできない場合は、「1. ディスク容量の枯渇」の手順に従って問題を解決してみてください。

   • 停止したすべてのコンテナーを削除するには、sudo docker container prune を実行します。

   • すべての dangling イメージ (タグのないイメージ) を削除するには、sudo docker image prune を実行します。

   • 未使用のビルドキャッシュを削除するには、sudo docker builder prune を実行します。

6. inotify watches の上限到達

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

1. 現在の inotify watches の上限を確認します。

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

2. inotify watches の上限値を引き上げます。

   上限値を引き上げると、inotify がより多くのシステムメモリを使用する可能性があります。変更を行う前に、この点を慎重に評価してください。<new_limit_value> は 524288 以下に設定することを推奨します。

   sudo sh -c "echo fs.inotify.max_user_watches=<new_limit_value> >> /etc/sysctl.conf"

3. 新しい設定をロードします。

   sudo sysctl --system を実行して新しい設定をロードし、変更を適用します。

4. 新しい設定を確認します。

   sudo cat /proc/sys/fs/inotify/max_user_watches を再度実行し、inotify watches の上限が期待する値に更新されたことを確認します。