Linux 磁盘爆满排查：df、du 与日志清理实操

服务器上最常见的半夜报警不是 CPU 飙高，而是磁盘满了。磁盘一满，数据库写不进去、日志打不出来、网站直接 500，一堆服务连锁遭殃。好消息是排查就两条命令：df 看整体，du 找元凶，再配一套清理组合拳，十分钟就能把机器救回来。

一、df：先看整体还剩多少

df -h

-h 是按人类可读单位显示。重点看 / 根分区的使用率（Use%）和剩余空间（Avail）。超过 85% 就要警惕，100% 就是事故现场。

还有一个容易被忽略的维度：inode。用完了 inode，就算磁盘空间还有剩，文件也建不出来：

df -i

小文件巨多的场景（比如缓存目录、邮件队列）最容易先耗尽 inode。看到 IUse% 接近 100%，排查思路就从“找大文件”改成“找数量多的目录”。

二、du：顺藤摸瓜找大户

从根目录一层一层往下钻：

du -sh /*
du -h --max-depth=1 /var | sort -rh | head -10

sort -rh 把最大的排在前面，十秒锁定嫌疑目录。常见的几位“惯犯”：

• /var/log：系统和应用日志，日积月累能吃掉几十 GB
• /var/lib/docker：Docker 镜像、容器层和卷，overlay2 目录经常悄悄膨胀
• /var/lib/mysql：数据库的 binlog 和慢查询日志
• /tmp 和 /var/tmp：临时文件没人清理，越堆越多
• 家目录下的备份包：随手打的 backup-2026.tar.gz，打完就忘了删

定位到具体文件用 find：

find /var/log -type f -size +500M -exec ls -lh {} \;

三、清理：先救命，再治本

日志是最安全的清理对象。systemd 的 journal 日志可以按大小瘦身：

journalctl --disk-usage        # 先看 journal 占了多少
journalctl --vacuum-size=500M  # 只保留最近 500M
journalctl --vacuum-time=7d    # 或只保留最近 7 天

正在被写的文件千万别直接 rm。进程还拿着文件句柄，rm 掉之后空间不会释放，还会让程序继续往一个“不存在”的文件里写。正确姿势是截断：

: > /var/log/nginx/access.log   # 清空内容，句柄还在，空间立即释放

应用日志如果带了时间轮转（比如 app.log.2026-10-27），旧文件直接删没问题，删之前确认没有进程在写它。

Docker 用户定期跑一次瘦身：

docker system prune -a --volumes   # 删掉没用的镜像、容器、网络和卷

–volumes 会删未使用的卷，跑之前确认没有重要数据只存在卷里。只想清镜像就去掉 --volumes。

四、预防：别让同一块石头绊倒两次

给 journal 设上限，编辑 /etc/systemd/journald.conf：

SystemMaxUse=500M
SystemMaxFileSize=100M

改完重启 systemd-journald，journal 就再也不会无限制膨胀。

给日志配 logrotate，/etc/logrotate.d/myapp 写几行：

/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
}

每天轮转一次、只留 7 天、自动压缩，日志再也不会失控。

加一个磁盘告警，一行 crontab 就够：

*/30 * * * * df -h / | awk 'NR==2 && $5+0 > 85 {print "磁盘告警：" $5}' | mail -s "磁盘空间告警" root

使用率过 85% 就发邮件，留出处理时间，别等到 100% 才半夜爬起来救火。

小结

磁盘爆满的排查就三步：df 看整体、du 找大户、针对性清理；inode 满了是另一条线，找文件数量多的目录。救完火记得做三件事：journal 设上限、日志配轮转、磁盘加告警。磁盘空间和内存一样，都是平时看着富余、关键时刻要命的资源，提前设好红线，比半夜抢修便宜得多。