Linux 磁盘空间排查三板斧：df、du 与 journalctl 实战

线上服务器最常见的告警之一，就是磁盘空间不足。根分区被写满后，服务写日志失败、数据库拒绝写入，甚至连 SSH 登录都可能受影响。本文结合实战经验，介绍 df、du、journalctl 这三个排查磁盘问题的利器。

第一板斧：df —— 先看整体

df -h 查看各挂载点的使用率，快速定位哪个分区满了：

df -h

输出中重点看 Use% 列。如果根分区 / 使用率超过 85%，就该着手清理了。加上 -T 还可以看到文件系统类型：

df -hT

注意：df 统计的是文件系统层面的已用空间。

第二板斧：du —— 找出“罪魁祸首”

知道哪个分区满了之后，用 du 自顶向下定位大目录：

du -sh /* 2>/dev/null | sort -rh | head -10

进入最大的目录继续下钻：

du -sh /var/* 2>/dev/null | sort -rh | head -10

几个实用技巧：

• du -sh：只显示总计，人性化单位；
• sort -rh：按人类可读的容量倒序排列；
• 排查时加上 2>/dev/null 过滤权限不足的报错；
• 定位到具体大文件：find /var -type f -size +100M -exec ls -lh {} \;。

常见的大户：/var/log 下的日志、/var/lib/docker（容器镜像与 overlay 层）、应用的堆转储文件。

一个经典陷阱：df 满了，du 却找不到大文件

有时 df 显示 100%，但 du 加总却远小于分区容量。最常见的原因是被删除但仍被进程占用的文件：文件被 rm 后，如果还有进程持有其句柄，空间不会释放。用 lsof 揪出来：

lsof | grep deleted

找到后重启对应进程（或清空对应 fd），空间立即释放。这也是“删了日志但空间没回来”的经典原因。

第三板斧：journalctl —— 管住 systemd 日志

很多机器的磁盘是被 journal 日志悄悄吃掉的。先看占用：

journalctl --disk-usage

如果动辄几个 GB，可以：

1. 按时间清理，保留最近 7 天：

   sudo journalctl --vacuum-time=7d
   

2. 按容量清理，限制在 500MB 以内：

   sudo journalctl --vacuum-size=500M
   

3. 治本：修改 /etc/systemd/journald.conf，设置 SystemMaxUse=500M 和 MaxFileSec=7day，然后 systemctl restart systemd-journald。

日志轮转：logrotate 别忘了

应用日志建议接入 logrotate。检查 /etc/logrotate.d/ 下是否有对应配置，确认 rotate、compress、maxsize 等参数合理。没有轮转的日志，一夜之间写满磁盘的案例并不少见。

排查流程小结

1. df -h：确认哪个分区满；
2. du -sh /* | sort -rh：逐层下钻找大目录/大文件；
3. lsof | grep deleted：排查“删了没释放”；
4. journalctl --disk-usage / --vacuum-size：收拾 systemd 日志；
5. 检查 logrotate，给日志加上轮转，防止复发。

掌握这三板斧，绝大多数磁盘空间问题都能在十分钟内定位解决。建议把磁盘使用率巡检做成定时任务，防患于未然。