服务器磁盘又满了？df、du、journalctl 三板斧

做后端开发，总会遇到服务器突然报警：磁盘使用率 95%。第一次遇到时我手忙脚乱，删了半天日志，空间一点没释放。后来总结出三个命令的固定排查流程，几分钟就能定位问题。这篇把这套方法写下来，给同样被磁盘报警吓过的人参考。

第一板斧：df，看整体

先看整台机器的磁盘使用情况：

df -h

-h 是以人类可读的方式显示（GB/MB）。重点看 / 根分区的使用率和挂载点。如果根分区到了 90% 以上，就要动手了。注意顺手看一下 tmpfs 和 overlay，这类是内存文件系统，占用的是内存不是磁盘，别被它吓到。

第二板斧：du，找大户

知道哪个分区满了，就用 du 逐层定位是谁吃掉了空间：

du -sh /var/* | sort -rh | head -10

这条命令列出 /var 下各目录的占用并按大小排序。顺着最大的目录一层层往下钻，几分钟就能找到元凶。经验之谈：嫌疑人通常是这三个——/var/log 下的系统日志、/var/lib/docker 下的容器层和日志、应用自己写的业务日志。我第一次排查，凶手就是 Docker 的 json 日志文件，一个容器攒了十几个 G。

第三板斧：journalctl，收日志

找到是日志的问题，别急着 rm -f。systemd 的日志用 journalctl 管理，先看看量有多大：

journalctl --disk-usage

如果 journal 占了几个 G，可以限制它的总大小并立刻生效：

sudo journalctl --vacuum-size=500M

这条命令会把 journal 日志压缩到 500M 以内。想一劳永逸，就去改 /etc/systemd/journald.conf，把 SystemMaxUse=500M 写进去，重启服务后长期有效。

删文件为什么空间没释放？

这是我当年踩过最深的坑：rm 删掉了日志文件，df 一看，空间一点没动。原因是文件还被某个进程占用着，Linux 要等所有打开它的进程关闭后才真正释放。用这条命令揪出它们：

lsof | grep deleted

看到被删但还占着空间的文件，要么重启对应服务，要么直接清空文件内容而不是删除文件：

: > /var/log/app/app.log

清空内容会立即释放空间，进程也不用重启。这是线上救急时最安全的一招。

顺手防一手：给 Docker 日志加个上限

既然凶手经常是 Docker 日志，不如从源头限制它。Docker 的 json-file 日志驱动默认不轮转，在 /etc/docker/daemon.json 里加上：

{
  "log-driver": "json-file",
  "log-opts": {"max-size": "50m", "max-file": "3"}
}

重启 Docker 后，每个容器的日志最多保留 3 个 50M 的文件，单个容器再也不会默默吃掉十几个 G。线上机器建议都配上，这是性价比最高的预防动作。

写在最后

磁盘满的排查其实有固定套路：df 看整体、du 找大户、journalctl 收日志，删文件前先确认没有进程占用。把这三板斧练熟，下次收到报警就不用慌了。更进一步的话，可以给日志加上 logrotate 轮转，或者把业务日志直接打到对象存储，让服务器本地只留最近几天的量，从源头上告别磁盘报警。