Linux インスタンスでアプリケーションやサービスを継続的に実行すると、ログ、キャッシュ、業務データが時間の経過とともに蓄積し、利用可能なディスク領域を徐々に消費します。ディスクがいっぱいになると新しいデータを書き込めなくなり、サービス中断や異常動作の直接的な原因になります。
症状
Linux インスタンスでファイルを作成したりアプリケーションを実行したりする際に、エラーメッセージ No space left on device が表示されます。これは、ストレージリソースが枯渇していることを示します。
診断と解決策
変更を行う前に、データをバックアップして業務に影響する偶発的なデータ損失を防ぐため、手動スナップショットを作成してください。
シナリオ 1：ディスク領域の枯渇
ディスク使用率を確認します。
sudo df -hを実行して、各マウントポイントのディスク使用率を確認します。Use%の値が 100% の場合、該当する領域がいっぱいです。ディスク領域を消費している大容量のファイルまたはディレクトリを特定してクリーンアップします。
ルートディレクトリから開始し、
sudo du -sh /*を実行して階層ごとに調査し、最も領域を消費しているディレクトリを素早く特定します。出力に基づいて使用量が最大のディレクトリを特定し、そのディレクトリで
sudo du -sh <directory name>/*を繰り返し実行して階層を掘り下げ、大容量ファイルを特定します。たとえば、
sudo du -sh /mnt/*を実行して、/mntディレクトリ配下のファイルとサブディレクトリが消費している領域を確認します。クリーンアップ可能な一般的な対象は次のとおりです。実際の業務要件に基づいて不要なファイルをクリーンアップしてください。
種類
一般的な場所
説明と推奨事項
ログファイル
/var/log
アプリケーションおよびシステムのログです。アーカイブされた過去ログをクリーンアップできます。systemd のログについては、書き込み中のログを
rmで直接削除するのではなく、sudo journalctl --vacuum-size=200 Mを使用してサイズを制限してください。一時ファイル
/tmp, /var/tmp
一時データです。プロセスが使用していないことを確認したうえでクリーンアップしてください。
アプリケーションキャッシュ / 業務ログ
カスタムの業務ディレクトリ
業務内容に応じた判断が必要です。クリーンアップする前に、重要なデータではないことを必ず確認し、誤削除を防いでください。
クリーンアップ後も領域が不足する場合は、ディスクを拡張してください。
シナリオ 2: inode リソースの枯渇
各ファイルは 1 つの inode を消費します。ディスクに多数の小さなファイルが含まれている場合、ディスク領域に空きがあっても inode が枯渇し、新しいファイルを作成できなくなることがあります。
inode 使用率を確認します。
sudo df -iを実行します。IUse%の値が 100% に達している場合、inode リソースが枯渇しています。不要なファイルまたはフォルダーをクリーンアップします。
sudo du -sh --inodes <folder name>/*を使用して、指定したディレクトリ内のファイルおよびサブフォルダーが使用している inode 数を確認します。必要に応じてディレクトリに移動し、このコマンドを再帰的に使用して inode 使用量が多い箇所を特定します。たとえば、
sudo du -sh --inodes /mnt/*を使用して、/mntディレクトリ配下のファイルとサブディレクトリが使用している inode 数を確認します。クリーンアップ後も inode 数が不足する場合は、ディスクを拡張してください。
シナリオ 3：削除済みファイルが領域を占有している
ファイルを削除しても、プロセスがそのファイルを引き続き使用している (つまり、開いたファイルハンドルを保持している) 場合、システムはディスク領域を解放しません。領域が解放されるのは、プロセスが終了するか、ファイルを明示的にクローズしたときのみです。
lsofツールをインストールします。削除済みでありながら領域を占有しているファイルは、
dfやduでは確認できません。lsofツールを使用して一覧表示します。Alibaba Cloud Linux、CentOS
sudo yum install -y lsofDebian、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)プロセス名とプロセス ID を記録します。
sudo lsof | grep '(deleted)'を実行し、COMMANDとPIDフィールドを確認して、プロセス名とプロセス ID を特定します。該当するサービスを再起動または停止します。
sudo ps -ef | grep <PID>を実行して、プロセスの用途を確認します。影響を評価したうえで、サービスを再起動または停止します。重要サービスの再起動または停止は、業務に影響する可能性があります。慎重に評価し、適切なメンテナンス時間帯に実施してください。
シナリオ 4：マウントポイントの重複
空ではないディレクトリを別のデバイスのマウントポイントとして使用すると、既存の内容は見えなくなります。ただし、すでにそのディレクトリを開いているプロセスは、下層の領域に書き込みを継続できます。この「隠れた」領域消費は df コマンドでは確認できず、予期せずディスク領域を枯渇させることがあります。
重複しているフォルダーに関する情報を確認します。
sudo lsblkを実行し、MOUNTPOINT 列で同じディレクトリ名が繰り返し表示されていないか確認します。sudo lsblkNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 253:0 0 40 G 0 disk ├─vda1 253:1 0 2 M 0 part ├─vda2 253:2 0 200 M 0 part /boot/efi └─vda3 253:3 0 39.8 G 0 part / vdb 253:16 0 40 G 0 disk └─vdb1 253:17 0 40 G 0 part /mnt vdc 253:32 0 40 G 0 disk └─vdc1 253:33 0 40 G 0 part /mntこの例では、
vdb1とvdc1の両方のパーティションが/mntにマウントされており、マウントポイントの重複のリスクがあることを示します。ファイルシステムをアンマウントします。
重要ファイルシステムのアンマウントにより、該当パスに依存するサービスが中断される可能性があります。リスクを評価し、適切な時間帯にこの操作を実施してください。
前の手順で
<duplicate mount directory>を取得できます。sudo umount <duplicate mount directory>この例では、
/mntが重複しているマウントディレクトリです。sudo umount /mntを実行すると、最後にマウントされたデバイスであるvdc1がアンマウントされます。重複しているマウントポイントのデバイス名を特定します。
sudo df -hを実行して、現在有効なマウントポイントに関連付けられているデバイス名を特定します。sudo df -hFilesystem Size Used Avail Use% Mounted on devtmpfs 3.7 G 0 3.7 G 0% /dev tmpfs 3.7 G 0 3.7 G 0% /dev/shm tmpfs 3.7 G 524 K 3.7 G 1% /run tmpfs 3.7 G 0 3.7 G 0% /sys/fs/cgroup /dev/vda3 40 G 4.5 G 33 G 12% / /dev/vda2 200 M 5.8 M 194 M 3% /boot/efi /dev/vdb1 40 G 40 G 0 100% /mnt tmpfs 747 M 0 747 M 0% /run/user/0この例では、現在
/mntにマウントされているパーティションはvdb1です。したがって、重複しているマウントポイントのデバイス名はvdb1です。ディスク領域の不足を解決します。
重複している領域内の不要なファイルまたはフォルダーをクリーンアップします。
この例では、
vdb1によってマウントされている/mntディレクトリをクリーンアップします。クリーンアップ後も領域が不足する場合は、ディスクを拡張し、別の空のディレクトリにマウントしてください。
この例では、拡張対象のデバイスは
vdb1です。
複数のデバイスを同じディレクトリにマウントしないでください。
複数のデバイスを同じディレクトリにマウントすると、先にマウントされたデバイスの領域が隠れ、誤ったデバイスにデータが書き込まれる可能性があります。必ず、異なるデバイスは別々の空のディレクトリにマウントしてください。
シナリオ 5：Docker 関連ファイルによる大幅な領域消費
Docker は動作中に、多数の中間イメージ、停止済みのコンテナ、ビルドキャッシュを生成します。時間の経過とともにこれらが蓄積し、ディスク領域を消費します。
Docker のディスク領域使用量を確認します。
sudo df -hを実行します。overlayタイプのFilesystemに対するUse%が 100% に達している場合、Docker ストレージがいっぱいです。Docker リソースの使用状況を評価します。
sudo docker system dfを実行し、SizeとRECLAIMABLEフィールドを確認して、領域消費の状況を把握します。sudo docker system dfTYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 21 9 13.94 GB 10.66 GB (76%) Containers 9 5 30.09 MB 0 B (0%) Local volumes 6 6 259.9 MB 0 B (0%) Build Cache 0 0 0 B 0 Bこの例では、
Dockerイメージが 13.94 GB を占有しており、そのうち 10.66 GB が再利用可能です。未使用のイメージのクリーンアップを優先することを推奨します。不要なファイルをクリーンアップします。
Docker ファイルをクリーンアップできない場合は、シナリオ 1：ディスク領域の枯渇の手順に従ってください。
すべての停止済みのコンテナを削除します：
sudo docker container pruneを実行します。すべての dangling イメージ (タグなしイメージ) を削除します：
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 watchの現在の上限を確認します。inotify watch の上限を引き上げます。
この上限値を引き上げると、メモリ使用量が増加します。変更する前に、慎重に評価してください。
<new limit>は、通常 524288 を超えないようにしてください。sudo sh -c "echo fs.inotify.max_user_watches=<new limit> >> /etc/sysctl.conf"新しい設定を読み込みます。
sudo sysctl --systemを実行して、更新した設定を適用します。結果を確認します。
sudo cat /proc/sys/fs/inotify/max_user_watchesを再度実行し、inotify watchの上限が想定どおりに更新されていることを確認します。
関連ドキュメント
画像、動画、アーカイブなどの静的ファイルを大量に保存する場合は、Object Storage Service (OSS) を使用してください。
高性能かつ高同時実行のファイル共有には、File Storage NAS を使用してファイルを保存してください。
大規模なログ収集と分析には、ログを Simple Log Service (SLS) に保存して、クエリを簡素化し、ローカルストレージ使用量を削減してください。