說明：這幾天發現生產環境中的一台應用服務器根目錄爆滿，但前期一直沒有找到問題所在。終於今天找到的問題並得以解決，在此分享下解決思路和方案，並同時做一個記錄。
操作系統：CenOS 7.9 根目錄文件占用正常，已重啟過服務器，也釋放過deleted進程，空間依然占用。
1>通過寶塔巡檢發現根目錄空間異常
2>使用“df -h"發現磁盤使用率已達到96%
[root@**_app ~]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 16G 0 16G 0% /dev tmpfs 16G 0 16G 0% /dev/shm tmpfs 16G 27M 16G 1% /run tmpfs 16G 0 16G 0% /sys/fs/cgroup /dev/mapper/centos-root 50G 48G 2.2G 96% / //*發現根目錄的容量已經使用了96% 只剩余2.2G的空間可供使用 /dev/sda1 1014M 237M 778M 24% /boot /dev/mapper/centos-home 827G 44G 783G 6% /home tmpfs 3.2G 0 3.2G 0% /run/user/0 //192.168.22.10/backup 1.0T 297G 728G 29% /windows [root@**_app ~]#
3>使用"df -i"查詢inode占用情況，發現占用率在3% 是正常的。
[root@**_app ~]# df -i Filesystem Inodes IUsed IFree IUse% Mounted on devtmpfs 4082131 509 4081622 1% /dev tmpfs 4085081 2 4085079 1% /dev/shm tmpfs 4085081 938 4084143 1% /run tmpfs 4085081 16 4085065 1% /sys/fs/cgroup /dev/mapper/centos-root 4687952 130756 4557196 3% / //*看到根目錄的inode占用率在3% 屬於正常情況 /dev/sda1 524288 341 523947 1% /boot /dev/mapper/centos-home 433352704 155813 433196891 1% /home tmpfs 4085081 1 4085080 1% /run/user/0 //192.168.22.10/backup 0 0 0 - /windows [root@**_app ~]#
4>查詢根目錄空間使用情況
進入根目錄：cd /
查看根目錄實際占用文件大小： du -h -x --max-depth=1
根目錄空間有50G，實際占用文件只有10G不到，另外占用的將近40GB的文件找不到。
[root@**_app ~]# cd / [root@**_app /]# du -h -x --max-depth=1 36M ./etc 720K ./root 456M ./var 212K ./tmp 1.7G ./usr 0 ./media 0 ./mnt 0 ./opt 0 ./srv 5.0G ./www 4.0K ./patch 7.2G . //*看到根目錄文件總用量在7.2G，沒有達到50G [root@**_app /]#
5>初期思路(刪除文件后占用空間未釋放導致)：
網上有教程說是已刪除的文件占用導致的空間未釋放。
通過：lsof / | grep deleted 指令，查看當前系統句柄對已刪除文件未釋放情況。
發現占用的文件大小是是空的(都是0)。所以可以排除文件占用的問題。
[root@**_app /]# lsof / |grep deleted php-fpm 9686 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9689 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9692 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9694 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9695 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9696 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9697 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9698 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9699 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9700 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9701 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9702 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9703 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9704 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9705 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9706 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9707 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9708 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) mysqld 10517 mysql 5u REG 253,0 0 67772106 /tmp/ibXplGAM (deleted) mysqld 10517 mysql 6u REG 253,0 0 67772642 /tmp/ibjllXSI (deleted) mysqld 10517 mysql 7u REG 253,0 0 68364239 /tmp/ibdxKebF (deleted) mysqld 10517 mysql 8u REG 253,0 0 68369312 /tmp/ib2aON9x (deleted) mysqld 10517 mysql 14u REG 253,0 0 68933157 /tmp/ibrdaFUu (deleted) php-fpm 10609 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 10662 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) [root@**_app /]#
如果是因為刪除了文件，且文件被程序占用導致資源未回收的這種問題的話，那么到這一步只要使用kill -hup pid號，進行殺死后會自動重啟，資源也得以釋放，問題便可以解決問題了。
但很顯然，我這邊碰到的並不是這個原因，所以還要尋找其它的解決方法，繼續排查：
6>Windows mount排查思路1：
最后考慮到之前有動過另一台Windows服務器的共享，該服務器的共享mouna(掛載)到Linux服務器的windows目錄中。遂開始排查該目錄情況。(SSH輸出內容中過濾了部分重復、隱私信息)
[root@**_app /]# cd /windows //*進入mount的windows目錄 [root@**_app windows]# ls //*查看目錄情況 database site //*發現有兩個目錄 [root@**_app windows]# cd database //*先查看database目錄 [root@**_app database]# du -sh * //*查看database目錄文件占用情況 41M db_**_dev_20211209_220002.sql.gz 41M db_**_dev_20211209_230002.sql.gz 41M db_**_dev_20211210_000001.sql.gz 41M db_**_dev_20211210_010001.sql.gz //*該目錄文件很多、后面不貼出來了，基本都在41M左右，與windwos服務器中查看的情況一致。 [root@**_app database]# [root@**_app database]# cd .. //*返回上級目錄 [root@**_app windows]# cd site //*查看site目錄 [root@**_app site]# du -sh * //*查看site目錄文件占用情況 41G web_saas.***.com.cn_20211211_010001.tar.gz 41G web_saas.***.com.cn_20211212_010001.tar.gz 41G web_saas.***.com.cn_20211213_010001.tar.gz 41G web_saas.***.com.cn_20211215_010002.tar.gz 41G web_saas.***.com.cn_20211216_010001.tar.gz 41G web_saas.***.com.cn_20211217_010001.tar.gz [root@**_app site]# //*看到site目錄和windows服務器下共享中的文件內容是一致的，所以剛開始的時候便排除了該目錄的問題
剛開始的時候排查過mount的目錄，因為其內容與Windows 服務器共享出來的內容一致，便很快排除了mount目錄的問題。
但后期一整套排查下來，近期只有動過這台服務器的共享，所以還是決定從mount上着手排查。
7>mount 排查 "umount":
先把掛載的windows目錄使用"umount"命令卸載看看結果：
[root@**_app site]# cd / //*進入根目錄 [root@**_app /]# umount windows //*對windows進行unmout [root@**_app /]# cd /windows //*進入根目錄下windows目錄 [root@**_app windows]# ls //*查看發現存在一個site目錄，正常情況下umount后應該是空的才對，感覺問題已經定位到了。繼續往下看 site [root@**_app windows]# cd site //*進入site目錄 [root@**_app site]# du -sh * //*查看site目錄文件占用情況 4.0K web_posapi.***.com.cn_20211214_010001.tar.gz 24M web_pos.***.com.cn_20211214_010001.tar.gz 41G web_saas.***.com.cn_20211214_010001.tar.gz //*最大的文件 4.0K web_www.***.com.cn_20211214_010001.tar.gz [root@**_app site]# //*多出來的40個G的空間終於定位到了....
至此，問題已經大致定位出來了，由於之前變動過windwos mount，導致當日網絡備份失敗，寶塔自動備份到根目錄的windows 目錄下了....
8>刪除占用文件：
進入到"/windows/site"目錄下，執行"rm -rf *"刪除當前目錄下所有文件。
注意：注意執行該命令前需要區分當前目錄，否則會刪錯，導致文件丟失
[root@**_app site]# rm -rf * //*刪除當前目錄下所有文件，注意執行該命令前需要區分當前目錄，否則會刪錯，導致文件丟失 [root@**_app site]# ls //*再次查看，文件已刪除 [root@**_app site]#
9>重新mount並核對：
[root@**_app site]# mount -a //*重新mount，因為我的mount配置是寫到fstab里面的，可以直接這樣操作 [root@**_app site]# df -h //*再次查看磁盤空間 Filesystem Size Used Avail Use% Mounted on devtmpfs 16G 0 16G 0% /dev tmpfs 16G 0 16G 0% /dev/shm tmpfs 16G 27M 16G 1% /run tmpfs 16G 0 16G 0% /sys/fs/cgroup /dev/mapper/centos-root 50G 7.3G 43G 15% / //*根目錄空間已釋放 /dev/sda1 1014M 237M 778M 24% /boot /dev/mapper/centos-home 827G 44G 783G 6% /home tmpfs 3.2G 0 3.2G 0% /run/user/0 //192.168.22.10/backup 1.0T 297G 728G 29% /windows //*mount也成功掛載 [root@**_app site]#
查看寶塔：
總結：
1.如果如果是因為刪除了文件，且文件被程序占用導致資源未回收的這種問題的話，那么到第5步的時候就可以解決問題了，后期再使用kill -hup pid號，進行殺死后會自動重啟，即可。
2.處理這類問題一定要結合近期的變動來處理，正常情況下只要程序沒有大動過，都可以排除程序的問題，再着手排查近期改動所帶來的影響。