Linux 磁盘满了先查哪里：df、du 与日志的排查顺序

服务器上最让人头疼的故障之一，就是磁盘突然满了。服务写不进日志、数据库拒绝写入、上传失败，报错五花八门，根因却常常只有一个：某个地方悄悄把空间吃光了。排查时最怕东一榔头西一棒子，本文给一个固定顺序：先看整体、再定位大目录、最后处理日志与缓存，十分钟内一般能找到元凶。

第一步：df 看整体，确认是哪块盘

先跑 df -h，看 Use% 最高的那一行。注意两点：一是挂载点，根分区满和数据盘满的处理完全不同；二是 df -i 也要顺手看一眼，inode 耗尽时磁盘明明还有空间，文件却一样建不出来，这种情况多见于小文件泛滥的缓存目录或邮件队列。

如果 Use% 只是 80% 出头、还在缓慢增长，先别急着删东西，用 du 定位后再动手。删错正在被进程写的文件，空间不一定释放，还可能把服务搞挂。

第二步：du 逐层下钻，找出大目录

从根目录或可疑挂载点开始，用 du -h --max-depth=1 / 2>/dev/null | sort -rh | head 列出最大的几项，再逐层进入最大的目录重复这个过程。2>/dev/null 是为了屏蔽无权限目录的报错。几轮下来，大目录一般就藏在 /var/log、/var/lib/docker、数据库数据目录或某个应用的上传目录里。

Docker 用户要特别留意 /var/lib/docker：长期不清理的悬空镜像、无用的卷和容器日志都长在这里。docker system df 能直接看到镜像、容器、卷各自占了多少，再决定用 docker system prune 还是只清卷。生产机器上 prune 之前务必确认没有要保留的已停容器和未命名卷。

第三步：日志是最常见的元凶，处理要讲方法

/var/log 里单个几 GB 的日志文件并不少见，尤其是某个服务陷入报错循环、每秒写几百行的时候。直接 rm 正在被写的文件并不能释放空间，因为进程还握着文件句柄，正确做法是先用 truncate -s 0 文件名 把它截断，或者重启对应服务后再删。更好的长期办法是确认 logrotate 是否在正常工作：/etc/logrotate.d/ 里对应服务的配置有没有轮转周期和保留份数，logrotate -d 可以模拟跑一次看它会做什么。

同样道理，journalctl 的持久日志也会膨胀。journalctl --disk-usage 看总量，journalctl --vacuum-size=500M 或 --vacuum-time=7d 可以按大小或时间清理，写进 /etc/systemd/journald.conf 的 SystemMaxUse 则是治本的配置。查问题时别忘了 journalctl -u 服务名 --since "1 hour ago" 这种按服务和时间过滤的组合，比全文翻日志快得多。

第四步：缓存与临时文件，分清能不能删

/tmp、应用缓存、包管理器的缓存都是可清理的候选，但要分清归属：包管理器缓存用自带命令清（如 apt clean），应用缓存先看文档或确认进程已停。数据库的临时文件、排序溢出文件则不能随手删，删之前先确认数据库状态正常。原则只有一条：不知道归属的文件，先 lsof 看有没有进程在用，或者先移到别处观察一天，确认服务正常再彻底删除。

最后：把排查变成预防

一次救火之后，值得顺手做三件事：一是给磁盘使用率设告警，85% 提醒、95% 紧急；二是把日志轮转和 journal 上限配好，别让日志无限长；三是定期跑一次 du 排序，看看增长最快的目录是不是符合预期。磁盘满从来不是突然发生的，它只是平时没人看的那条曲线，终于顶到了上限。养成先看整体、再定位、最后动手的顺序，下次告警响起时，你就不用再凭运气删文件了。