​​Linux根分区爆满（占用81%）排查与解决实战

Linux根分区爆满占用81%排查与解决实战在Linux服务器运维过程中根分区爆满是非常常见的紧急故障若不及时处理会导致服务器无法正常运行、服务卡顿甚至崩溃。本文以本人Java技术人员的视角记录一次CentOS服务器根分区占用81%的完整排查、定位与解决过程——运维同事先告知服务器磁盘空间报警且已自行删除对应的大文件但未将删除操作及后续情况通知我导致我排查时出现诸多异常全程实操可复现适合Java技术人员、运维新手参考学习。一、故障现象登录服务器后执行常规磁盘空间查询命令df -h发现根分区/异常[rootlocalhost /]# 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 /执行命令查询所有一级目录的占用大小并按从大到小排序[rootlocalhost /]# 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结果不一致”的情况大概率是文件已被删除但对应的进程仍在占用该文件导致磁盘空间未释放。被删除的文件此时会变成“隐形文件”常规查询无法发现但会持续占用磁盘空间这也解释了为什么运维同事删除大文件后磁盘占用依然居高不下且我排查时会出现“目录占用与磁盘已用严重不匹配”的异常。执行以下命令查找所有被删除但仍被进程占用的文件[rootlocalhost /]# 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进程对于这种“进程占用已删除文件”的场景有两种解决方式重启占用文件的进程简单直接但会导致服务中断不适合生产环境核心服务清空进程占用的文件描述符无需重启进程瞬间释放空间适合生产环境。本次采用第二种方式针对Java进程PID26192的文件描述符1和2对应stdout和stderr执行清空操作[rootlocalhost /]# /proc/26192/fd/1 [rootlocalhost /]# /proc/26192/fd/2命令说明/proc/[PID]/fd/目录下存放着进程打开的所有文件描述符“1”对应标准输出“2”对应标准错误符号表示清空文件内容而非删除文件执行后会立即释放该文件占用的磁盘空间。执行完成后再次执行df -h验证根分区使用率已降至正常水平约8%空间释放成功。五、补充优化处理次要占用与避免复发1. 清理zabbix-agent占用的已删除文件除Java进程外zabbix-agent进程也占用了少量已删除文件日志和PID文件虽不影响磁盘空间但为了系统整洁重启zabbix-agent服务即可释放[rootlocalhost /]# systemctl restart zabbix-agent2. 避免后续再出现类似问题本次故障的根源是运维同事告知我服务器磁盘空间报警后自行删除了持续增大的nohup.out大文件但未通知我这一操作也未检查该文件对应的Java进程是否释放文件句柄同时最初使用nohup启动Java服务时未处理输出日志导致nohup.out文件持续增大多重因素叠加最终导致磁盘爆满。针对此问题给出两个优化方案同时规范团队沟通与操作流程丢弃nohup输出推荐无需日志时nohup java -jar xxx.jar /dev/null 21 说明/dev/null表示丢弃输出21表示将标准错误重定向到标准输出最终所有输出都被丢弃不会生成nohup.out文件。配置日志轮转需要保留日志时 使用logrotate工具对nohup.out或Java应用日志进行轮转设置日志大小限制、保留天数避免日志无限增大。六、总结与复盘本次故障排查核心逻辑df -h发现磁盘爆满 →du -sh *排查目录占用发现异常大小不匹配 →lsof | grep deleted定位进程占用的已删除文件 → 清空文件描述符释放空间 → 优化配置避免复发。关键知识点df查看磁盘分区整体使用情况du查看目录/文件具体占用大小两者结果不一致时优先考虑“进程占用已删除文件”lsof | grep deleted是定位此类问题的核心命令可快速找到隐形占用文件生产环境中避免直接重启核心服务优先使用“清空文件描述符”的方式释放空间减少服务中断风险。通过本次排查不仅解决了磁盘爆满问题还掌握了“进程占用已删除文件”的排查技巧同时也提醒团队运维操作需规范、沟通需及时——运维同事执行删除大文件等关键操作后需及时通知相关技术人员如Java开发/技术人员且必须检查对应进程是否释放文件句柄避免其他人员排查时出现困惑后续可通过规范日志管理、明确团队沟通与操作流程彻底避免此类故障再次发生。