在Linux服務器運維過程中，根分區(qū)爆滿是非常常見的緊急故障，若不及時處理，會導致服務器無法正常運行、服務卡頓甚至崩潰。本文以本人（Java技術人員）的視角，記錄一次CentOS服務器根分區(qū)占用81%的完整排查、定位與解決過程——運維同事先告知服務器磁盤空間報警，且已自行刪除對應的大文件，但未將刪除操作及后續(xù)情況通知我，導致我排查時出現(xiàn)諸多異常，全程實操可復現(xiàn)，適合Java技術人員、運維新手參考學習。

一、故障現(xiàn)象

登錄服務器后，執(zhí)行常規(guī)磁盤空間查詢命令 df -h，發(fā)現(xiàn)根分區(qū)（/）異常：

[root@localhost /]# df -h
Filesystem               Size  Used Avail Use% Mounted on
devtmpfs                 7.8G     0  7.8G   0% /dev
tmpfs                    7.8G     0  7.8G   0% /dev/shm
tmpfs                    7.8G  161M  7.6G   3% /run
tmpfs                    7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/mapper/centos-root   50G   41G  9.7G  81% /
/dev/sda1               1014M  150M  865M  15% /boot
/dev/mapper/centos-home   42G  699M   41G   2% /home
tmpfs                    1.6G     0  1.6G   0% /run/user/0

根分區(qū)總大小50G，已使用41G，使用率達81%，剩余空間不足10G，隨時可能爆滿。按照常規(guī)思路，先排查根目錄下各文件夾的占用情況，定位大文件。

二、初步排查：定位根目錄大文件夾

切換到根目錄（cd /），執(zhí)行命令查詢所有一級目錄的占用大小，并按從大到小排序：

[root@localhost /]# du -sh * | sort -hr

執(zhí)行結果出現(xiàn)異常：所有目錄占用大小相加不足4G，與df -h顯示的41G已用空間嚴重不符，且出現(xiàn)部分無法訪問的提示（proc目錄相關，屬正常現(xiàn)象）：

du: cannot access ‘proc/25935/task/25935/fd/4': No such file or directory
du: cannot access ‘proc/25935/task/25935/fdinfo/4': No such file or directory
1.9G    usr
667M    home
640M    var
334M    opt
161M    run
147M    root
118M    boot
32M     etc
68K     tmp
0       sys
0       srv
0       sbin
0       proc
0       mnt
0       media
0       lib64
0       lib
0       dev
0       bin

三、關鍵定位：找到“隱形”占用文件

排查到這里陷入疑惑：所有目錄占用相加不足4G，與df -h顯示的41G已用空間嚴重不符，后續(xù)與運維同事溝通后才得知，運維同事在告知我磁盤空間報警后，已自行刪除了服務器上的大文件（即后續(xù)定位到的nohup.out文件），但未及時通知我這一操作，也未檢查該大文件對應的Java進程是否釋放文件句柄。結合運維經驗，這種“du與df結果不一致”的情況，大概率是 文件已被刪除，但對應的進程仍在占用該文件，導致磁盤空間未釋放。被刪除的文件此時會變成“隱形文件”，常規(guī)查詢無法發(fā)現(xiàn)，但會持續(xù)占用磁盤空間，這也解釋了為什么運維同事刪除大文件后，磁盤占用依然居高不下，且我排查時會出現(xiàn)“目錄占用與磁盤已用嚴重不匹配”的異常。

執(zhí)行以下命令，查找所有被刪除但仍被進程占用的文件：

[root@localhost /]# lsof | grep deleted

執(zhí)行結果瞬間定位到元兇：一個Java進程（PID為26192）占用了一個已刪除的nohup.out文件，該文件大小高達37.8G，正是導致根分區(qū)爆滿的核心原因！同時還有zabbix-agent進程占用少量已刪除文件（影響可忽略）。

核心異常輸出片段：

java      26192          root    1w      REG              253,0 37889443145   34805216 /opt/unionpay/nohup.out (deleted)
java      26192          root    2w      REG              253,0 37889443145   34805216 /opt/unionpay/nohup.out (deleted)

補充說明：lsof 命令用于查看進程打開的文件，grep deleted 篩選出已被刪除但仍被進程占用的文件；輸出中“37889443145”即為文件大?。s35.3G），“26192”是占用該文件的Java進程PID，“1w”“2w”表示進程的標準輸出（stdout）和標準錯誤（stderr）仍指向該文件。

四、解決方案：釋放空間（無需重啟Java進程）

對于這種“進程占用已刪除文件”的場景，有兩種解決方式：

1. 重啟占用文件的進程：簡單直接，但會導致服務中斷（不適合生產環(huán)境核心服務）；
2. 清空進程占用的文件描述符：無需重啟進程，瞬間釋放空間，適合生產環(huán)境。

本次采用第二種方式，針對Java進程（PID=26192）的文件描述符（1和2，對應stdout和stderr）執(zhí)行清空操作：

[root@localhost /]# > /proc/26192/fd/1
[root@localhost /]# > /proc/26192/fd/2

命令說明：/proc/[PID]/fd/ 目錄下存放著進程打開的所有文件描述符，“1”對應標準輸出，“2”對應標準錯誤；> 符號表示清空文件內容（而非刪除文件），執(zhí)行后會立即釋放該文件占用的磁盤空間。

執(zhí)行完成后，再次執(zhí)行 df -h 驗證，根分區(qū)使用率已降至正常水平（約8%），空間釋放成功。

五、補充優(yōu)化：處理次要占用與避免復發(fā)

1. 清理zabbix-agent占用的已刪除文件

除Java進程外，zabbix-agent進程也占用了少量已刪除文件（日志和PID文件），雖不影響磁盤空間，但為了系統(tǒng)整潔，重啟zabbix-agent服務即可釋放：

[root@localhost /]# systemctl restart zabbix-agent

2. 避免后續(xù)再出現(xiàn)類似問題

本次故障的根源是：運維同事告知我服務器磁盤空間報警后，自行刪除了持續(xù)增大的nohup.out大文件，但未通知我這一操作，也未檢查該文件對應的Java進程是否釋放文件句柄；同時，最初使用nohup啟動Java服務時，未處理輸出日志，導致nohup.out文件持續(xù)增大，多重因素疊加，最終導致磁盤爆滿。針對此問題，給出兩個優(yōu)化方案，同時規(guī)范團隊溝通與操作流程：

1. 丟棄nohup輸出（推薦，無需日志時）： nohup java -jar xxx.jar > /dev/null 2>&1 & 說明：/dev/null 表示丟棄輸出，2>&1 表示將標準錯誤重定向到標準輸出，最終所有輸出都被丟棄，不會生成nohup.out文件。
2. 配置日志輪轉（需要保留日志時）： 使用logrotate工具對nohup.out或Java應用日志進行輪轉，設置日志大小限制、保留天數(shù)，避免日志無限增大。

六、總結與復盤

本次故障排查核心邏輯：df -h 發(fā)現(xiàn)磁盤爆滿 → du -sh * 排查目錄占用，發(fā)現(xiàn)異常（大小不匹配） → lsof | grep deleted 定位進程占用的已刪除文件 → 清空文件描述符釋放空間 → 優(yōu)化配置避免復發(fā)。

關鍵知識點：

• df 查看磁盤分區(qū)整體使用情況，du 查看目錄/文件具體占用大小，兩者結果不一致時，優(yōu)先考慮“進程占用已刪除文件”；
• lsof | grep deleted 是定位此類問題的核心命令，可快速找到隱形占用文件；
• 生產環(huán)境中，避免直接重啟核心服務，優(yōu)先使用“清空文件描述符”的方式釋放空間，減少服務中斷風險。

通過本次排查，不僅解決了磁盤爆滿問題，還掌握了“進程占用已刪除文件”的排查技巧，同時也提醒團隊：運維操作需規(guī)范、溝通需及時——運維同事執(zhí)行刪除大文件等關鍵操作后，需及時通知相關技術人員（如Java開發(fā)/技術人員），且必須檢查對應進程是否釋放文件句柄，避免其他人員排查時出現(xiàn)困惑；后續(xù)可通過規(guī)范日志管理、明確團隊溝通與操作流程，徹底避免此類故障再次發(fā)生。

以上就是Linux根分區(qū)爆滿(占用81%)排查與解決方案的詳細內容，更多關于Linux根分區(qū)爆滿排查與解決的資料請關注腳本之家其它相關文章！

最新評論