Elastic Compute Service：解決Linux執行個體磁碟空間滿問題

情境一：磁碟空間耗盡

1. 查看磁碟使用率。

   系統下執行sudo df -h，查看各掛載點的磁碟使用方式，若Use%為100%，則說明對應空間已滿。

2. 清理無用的檔案或目錄。

   使用sudo du -sh <目錄名稱>/*，查看指定目錄下的檔案及子目錄的大小。若有需要，可進入目錄，逐級查看佔用情況。

   例如使用sudo du -sh /mnt/*，查看/mnt目錄下檔案及子目錄佔用空間的大小。

3. 若清理後仍空間不足，可擴容雲端硬碟。

情境二：Inode資源耗盡

每個檔案都會佔用一個Inode。如果磁碟上存在大量小檔案，即使磁碟空間有剩餘，Inode 也可能被耗盡，導致無法建立檔案。

1. 查看Inode使用率。

   執行命令sudo df -i，若IUse%達到100%，則表示Inode資源已耗盡。

2. 清理無用的檔案或目錄。

   可使用sudo du -sh --inodes <目錄名稱>/*，查看指定目錄下的檔案及子目錄佔用的Inode數量。若有需要，可進入目錄，利用此命令逐級查看佔用情況。

   例如使用sudo du -sh --inodes /mnt/*查看/mnt目錄下檔案及子目錄佔用空間的大小。

3. 若清理後Inode數仍不足，可擴容雲端硬碟。

情境三：存在已刪除未釋放空間的檔案

即使一個檔案被刪除，只要仍有進程正在使用（即持有其檔案控制代碼），系統就不會釋放其佔用的磁碟空間，直至進程終止或主動關閉檔案後才會被真正回收。

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列為檔案大小（單位Byte），累加可計算未釋放空間總量。

3. 記錄佔用進程的名稱和PID。

   執行sudo lsof | grep delete指令，通過COMMAND和PID欄位擷取進程名稱和進程PID。

4. 重啟或停止相關服務。

   執行sudo ps -ef | grep <PID>，進一步確認進程用途，評估影響後重啟或停止相關服務。

   重要

   重啟或停止服務可能會影響業務，請謹慎評估，選擇合適時間進行操作。

情境四：掛載點被覆蓋。

非空目錄被其他裝置掛載後，其下資料雖會被隱藏，但已開啟此目錄的進程仍可寫入覆蓋空間。此類“隱藏”空間消耗無法通過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. 卸載檔案系統。

   重要

   卸載檔案系統，可能導致依賴該路徑的服務中斷，請評估風險，選擇合適的時間操作。

   <重複掛載目錄>可通過上一步擷取。

   sudo umount <重複掛載目錄>

   樣本中/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的分區名稱為vdb1，因此被覆蓋掛載點的裝置名稱為vdb1。

4. 解決磁碟空間滿問題。

   1. 清理被覆蓋空間中無用的檔案或目錄。

      樣本中，需要清理vdb1掛載的/mnt目錄。

   2. 若清理後空間仍不足，可擴容雲端硬碟後，掛載至其他空目錄下使用。

      樣本中，需要擴容的目標裝置名稱為vdb1。

情境五：Docker相關檔案佔用空間較大。

Docker運行過程中會產生大量中間鏡像、已停止容器和構建緩衝，這些對象長期積累會佔用磁碟空間。

1. 查看Docker檔案磁碟空間佔用率。

   執行sudo df -h，Filesystem為overlay的Use%達到100%。

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.94GB，其中10.66GB可回收，建議優先清理無用鏡像。

3. 清理無用檔案。

   若Docker檔案無法清理，可嘗試依照情境一：磁碟空間耗盡處理問題。

   • 清除所有已停止的容器：執行sudo docker container prune。

   • 清除所有dangling鏡像（即無tag的鏡像）：執行sudo docker image prune。

   • 清除不再使用的構建緩衝：執行sudo docker builder prune。

情境六：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佔用更多系統記憶體，在修改前請謹慎評估，<新的上限值>一般不建議超過524288。

   sudo sh -c "echo fs.inotify.max_user_watches=<新的上限值> >> /etc/sysctl.conf"

3. 載入新配置。

   執行sudo sysctl --system載入新配置並使其生效。

4. 驗證配置結果。

   再次執行sudo cat /proc/sys/fs/inotify/max_user_watches命令，確認已更新為預期的inotify watches上限。