CentOS根分区爆满诊断与5大隐藏空间杀手处理-代码聚汇网

CentOS根分区爆满诊断与5大隐藏空间杀手处理

眠子子子

1. 根分区爆满的紧急处理流程

当CentOS 7.9系统弹出"No space left on device"告警时，我们需要立即执行以下诊断流程。首先通过df -h确认根分区使用率确实达到100%，这个命令会直观显示各挂载点的空间占用情况。典型输出如下：

code复制Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        50G   50G     0 100% /

注意：如果发现Use%显示为95%以上就应当立即处理，不要等到100%才行动，此时系统可能已经出现部分功能异常。

接下来使用du -sh /* | sort -rh | head -10快速定位占用最高的前10个目录。这个命令会扫描根目录下所有一级子目录的大小并按降序排列。常见异常情况包括：

/var/log 目录下堆积数GB的日志文件
/tmp 目录存在未被清理的临时文件
/home 用户目录下的缓存文件失控增长

如果发现某个特定目录异常膨胀，可以继续用du -sh /path/to/dir/* | sort -rh向下钻取，直到定位到具体的罪魁祸首文件。

2. 隐藏磁盘占用的五大元凶

2.1 nohup.out日志黑洞

这是最常见的隐形空间杀手。当用户使用nohup command &方式启动后台进程时，默认会将所有输出重定向到当前目录的nohup.out文件。这个文件会持续增长且不会自动轮转，几个月就可能吃掉数十GB空间。

解决方案：

立即清理现有文件：

bash复制# 先确认文件大小
ls -lh nohup.out
# 安全清空内容（比直接删除更安全）
> nohup.out

预防措施：

bash复制# 推荐启动方式（将输出重定向到/dev/null）
nohup command >/dev/null 2>&1 &
# 或者指定固定大小的日志文件
nohup command >> /var/log/myapp.log 2>&1 &

2.2 失控的systemd日志

journald日志系统默认配置下会占用最多10%的根分区空间（在/run/log/journal目录）。检查当前占用：

bash复制journalctl --disk-usage

优化方案：

bash复制# 修改配置文件/etc/systemd/journald.conf
SystemMaxUse=100M  # 限制总大小
SystemMaxFileSize=20M  # 限制单个文件大小
# 重启服务生效
systemctl restart systemd-journald

2.3 未轮转的应用程序日志

许多服务（如nginx、tomcat）默认不会自动清理日志。以nginx为例：

bash复制# 检查日志目录大小
du -sh /var/log/nginx/

配置logrotate实现自动轮转：

bash复制# 编辑/etc/logrotate.d/nginx
/var/log/nginx/*.log {
    daily
    missingok
    rotate 30
    compress
    delaycompress
    notifempty
    create 640 nginx adm
    sharedscripts
    postrotate
        /bin/kill -USR1 `cat /run/nginx.pid 2>/dev/null` 2>/dev/null || true
    endscript
}

2.4 被遗忘的yum缓存

yum操作会保留下载的rpm包，长期积累可能占用数GB空间：

bash复制# 查看缓存大小
du -sh /var/cache/yum
# 清理所有缓存
yum clean all

建议在/etc/yum.conf中添加：

code复制keepcache=0  # 禁用缓存保留

2.5 僵尸容器与镜像

如果系统运行过Docker，残留的容器和镜像可能占用惊人空间：

bash复制# 查看docker存储使用情况
docker system df
# 清理所有无用对象
docker system prune -a -f

3. 高级诊断技巧

3.1 查找被删除但仍占空间的文件

当进程持有已删除文件的句柄时，空间不会真正释放。使用以下命令检测：

bash复制lsof +L1 | grep deleted

处理方案：

bash复制# 找到对应进程ID后，选择重启进程
kill -9 <PID>
# 或者直接清空文件
> /proc/<PID>/fd/<FD_NUM>

3.2 inode耗尽问题

有时空间未满但inode用尽也会导致类似问题：

bash复制df -i  # 查看inode使用情况

清理小文件集群：

bash复制# 查找包含大量文件的目录
find / -xdev -printf '%h\n' | sort | uniq -c | sort -k1 -n

4. 长效预防机制

4.1 自动化监控配置

设置cron任务定期检查磁盘空间：

bash复制# 编辑/etc/cron.daily/disk-check
#!/bin/bash
ADMIN="admin@example.com"
THRESHOLD=90

CURRENT=$(df / --output=pcent | tail -1 | tr -d '% ')
if [ $CURRENT -gt $THRESHOLD ]; then
    df -h | mail -s "Disk Space Alert on $(hostname)" $ADMIN
fi

4.2 分区规划最佳实践

新建系统时应遵循以下分区方案：

/boot：1GB (ext4)
/：30-50GB (xfs)
/var：单独分区 50GB+ (xfs)
/home：根据用户数据需求分配
swap：物理内存的1-2倍

4.3 日志管理统一策略

建议所有应用日志统一记录到/var/log下的子目录，并配置统一的logrotate策略：

bash复制# /etc/logrotate.d/custom
/var/log/*/*.log {
    weekly
    missingok
    rotate 12
    compress
    delaycompress
    notifempty
    create 640 root adm
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

5. 应急扩容方案

当清理空间仍不能满足需求时，可考虑在线扩容：

如果是LVM分区：

bash复制# 查看VG剩余空间
vgs
# 扩展LV
lvextend -L +10G /dev/mapper/centos-root
# 调整文件系统
xfs_growfs /  # 对于xfs文件系统
resize2fs /dev/mapper/centos-root  # 对于ext4

如果是云主机，通常需要先通过控制台扩容云盘，再执行上述LVM操作。

我在管理生产服务器时曾遇到一个典型案例：某台服务器根分区突然爆满，最终发现是一个Java应用的GC日志配置错误，每天产生2GB的日志文件。这个经历让我养成了部署新应用时必须确认日志配置的习惯。建议所有关键操作前先用df -h看一眼空间余量，这个简单的习惯能避免90%的磁盘危机。