昨晚凌晨两点，报警系统疯狂弹窗：某台核心业务服务器的接口大量返回 500 错误。
紧急登录服务器查看，发现业务进程全挂了，敲个 tab 键补全命令都提示：No space left on device。

老运维一听就知道，磁盘被撑爆了。今天复盘一下处理这种紧急故障的“三板斧”。

第一斧：锁定罪魁祸首 (df 与 du 的配合)

首先运行 df -h 确认是哪个挂载点满了。通常是 / 根目录。
接着，我们要找出是谁吃掉了空间。回到根目录，运行这行极其好用的命令：

1
du -sh /* 2>/dev/null | sort -hr | head -n 5

这会列出当前目录下占用空间最大的前 5 个文件夹。一路追踪下去，我发现是 /var/log/nginx/ 目录竟然有 80GB！

[在这里插入一张 Linux 终端运行 du 命令查空间的截图]

第二斧：小心“幽灵文件”

找到大日志文件后，很多新手的操作是：rm -rf access.log。
这是致命的错误！ 如果 Nginx 进程还在运行，并且持有着这个文件的句柄，你用 rm 删除后，磁盘空间是不会释放的！(俗称幽灵文件)。

正确的清空正在被使用的文件的方法是：

1
cat /dev/null > /var/log/nginx/access.log

瞬间，磁盘空间释放，报警解除，服务恢复。

第三斧：治本之策 (Logrotate)

故障虽然排除了，但这完全是“人祸”。生产环境的日志绝不能让它无限膨胀。必须配置 Linux 自带的 logrotate 工具进行日志按天切割并压缩。

在 /etc/logrotate.d/ 目录下为你的服务写个配置，自动保留最近 7 天的压缩日志，从此再无磁盘撑爆的烦恼。