Linux根分区爆满(占用81%)排查与解决方案

在Linux服务器运维过程中，根分区爆满是非常常见的紧急故障，若不及时处理，会导致服务器无法正常运行、服务卡顿甚至崩溃。本文以本人（Java技术人员）的视角，记录一次CentOS服务器根分区占用81%的完整排查、定位与解决过程——运维同事先告知服务器磁盘空间报警，且已自行删除对应的大文件，但未将删除操作及后续情况通知我，导致我排查时出现诸多异常，全程实操可复现，适合Java技术人员、运维新手参考学习。

一、故障现象

登录服务器后，执行常规磁盘空间查询命令 df -h，发现根分区（/）异常：

[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

根分区总大小50G，已使用41G，使用率达81%，剩余空间不足10G，随时可能爆满。按照常规思路，先排查根目录下各文件夹的占用情况，定位大文件。

二、初步排查：定位根目录大文件夹

切换到根目录（cd /），执行命令查询所有一级目录的占用大小，并按从大到小排序：

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

执行结果出现异常：所有目录占用大小相加不足4G，与df -h显示的41G已用空间严重不符，且出现部分无法访问的提示（proc目录相关，属正常现象）：

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已用空间严重不符，后续与运维同事沟通后才得知，运维同事在告知我磁盘空间报警后，已自行删除了服务器上的大文件（即后续定位到的nohup.out文件），但未及时通知我这一操作，也未检查该大文件对应的Java进程是否释放文件句柄。结合运维经验，这种“du与df结果不一致”的情况，大概率是 文件已被删除，但对应的进程仍在占用该文件，导致磁盘空间未释放。被删除的文件此时会变成“隐形文件”，常规查询无法发现，但会持续占用磁盘空间，这也解释了为什么运维同事删除大文件后，磁盘占用依然居高不下，且我排查时会出现“目录占用与磁盘已用严重不匹配”的异常。

执行以下命令，查找所有被删除但仍被进程占用的文件：

[root@localhost /]# lsof | grep deleted

执行结果瞬间定位到元凶：一个Java进程（PID为26192）占用了一个已删除的nohup.out文件，该文件大小高达37.8G，正是导致根分区爆满的核心原因！同时还有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”即为文件大小（约35.3G），“26192”是占用该文件的Java进程PID，“1w”“2w”表示进程的标准输出（stdout）和标准错误（stderr）仍指向该文件。

四、解决方案：释放空间（无需重启Java进程）

对于这种“进程占用已删除文件”的场景，有两种解决方式：

1. 重启占用文件的进程：简单直接，但会导致服务中断（不适合生产环境核心服务）；
2. 清空进程占用的文件描述符：无需重启进程，瞬间释放空间，适合生产环境。

本次采用第二种方式，针对Java进程（PID=26192）的文件描述符（1和2，对应stdout和stderr）执行清空操作：

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

命令说明：/proc/[PID]/fd/ 目录下存放着进程打开的所有文件描述符，“1”对应标准输出，“2”对应标准错误；> 符号表示清空文件内容（而非删除文件），执行后会立即释放该文件占用的磁盘空间。

执行完成后，再次执行 df -h 验证，根分区使用率已降至正常水平（约8%），空间释放成功。

五、补充优化：处理次要占用与避免复发

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

除Java进程外，zabbix-agent进程也占用了少量已删除文件（日志和PID文件），虽不影响磁盘空间，但为了系统整洁，重启zabbix-agent服务即可释放：

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

2. 避免后续再出现类似问题

本次故障的根源是：运维同事告知我服务器磁盘空间报警后，自行删除了持续增大的nohup.out大文件，但未通知我这一操作，也未检查该文件对应的Java进程是否释放文件句柄；同时，最初使用nohup启动Java服务时，未处理输出日志，导致nohup.out文件持续增大，多重因素叠加，最终导致磁盘爆满。针对此问题，给出两个优化方案，同时规范团队沟通与操作流程：

1. 丢弃nohup输出（推荐，无需日志时）： nohup java -jar xxx.jar > /dev/null 2>&1 & 说明：/dev/null 表示丢弃输出，2>&1 表示将标准错误重定向到标准输出，最终所有输出都被丢弃，不会生成nohup.out文件。
2. 配置日志轮转（需要保留日志时）： 使用logrotate工具对nohup.out或Java应用日志进行轮转，设置日志大小限制、保留天数，避免日志无限增大。

六、总结与复盘

本次故障排查核心逻辑：df -h 发现磁盘爆满 → du -sh * 排查目录占用，发现异常（大小不匹配） → lsof | grep deleted 定位进程占用的已删除文件 → 清空文件描述符释放空间 → 优化配置避免复发。

关键知识点：

• df 查看磁盘分区整体使用情况，du 查看目录/文件具体占用大小，两者结果不一致时，优先考虑“进程占用已删除文件”；
• lsof | grep deleted 是定位此类问题的核心命令，可快速找到隐形占用文件；
• 生产环境中，避免直接重启核心服务，优先使用“清空文件描述符”的方式释放空间，减少服务中断风险。

通过本次排查，不仅解决了磁盘爆满问题，还掌握了“进程占用已删除文件”的排查技巧，同时也提醒团队：运维操作需规范、沟通需及时——运维同事执行删除大文件等关键操作后，需及时通知相关技术人员（如Java开发/技术人员），且必须检查对应进程是否释放文件句柄，避免其他人员排查时出现困惑；后续可通过规范日志管理、明确团队沟通与操作流程，彻底避免此类故障再次发生。

以上就是Linux根分区爆满(占用81%)排查与解决方案的详细内容，更多关于Linux根分区爆满排查与解决的资料请关注脚本之家其它相关文章！

最新评论