ECS 磁盘爆满的排查与清理实战

一次华为云 ECS 磁盘告警的完整排查：从 95% 占用到根治的实战记录

一次凌晨收到的磁盘告警，最后牵出三个不同层面的问题：日志失控、Docker 镜像堆积、一个被遗忘的临时目录。本文记录完整的排查思路和每一步的实际命令输出，希望能给遇到同样问题的人一个可以照着走的路径。

环境：华为云 ECS，2vCPU/4GB，Ubuntu 22.04，系统盘 40GB，跑了 Docker 服务、一个 Spring Boot 应用和定时任务。

一、告警来临

凌晨两点收到云监控的告警：磁盘使用率超过 90%。登上去第一件事先看整体情况：

df -h

输出关键行：

/dev/vda1        40G   38G   1.1G  98% /

40GB 用掉 38GB，只剩 1.1G，随时可能因为写不进日志导致服务挂掉。注意这时千万不要急着重启服务或删文件，先搞清楚空间去哪了。

二、定位空间去向

第一层：看各目录占用。

sudo du -xh --max-depth=1 / 2>/dev/null | sort -rh | head -15

用 -x 参数限制在当前文件系统（不跨挂载点），避免扫到挂载的云盘把结果搞混。输出排序后前几名：

12G  /var
8.4G /root
6.2G /opt
3.1G /usr
1.9G /home

/var 和 /root 是大头。继续往里钻：

sudo du -xh --max-depth=2 /var 2>/dev/null | sort -rh | head -10

结果指向 /var/lib/docker（8GB+）和 /var/log/journal（3GB+）。/root 下面则是一个 6GB 的 dumps 目录。

至此三个嫌疑人锁定：Docker、systemd 日志、以及一个手工创建的转储目录。逐个处理。

三、第一刀：systemd journal 日志

Ubuntu 22.04 的 journald 默认不限制日志大小上限（其实是持久化后无上限策略），长期运行的服务一旦刷日志，几个 GB 很快就没了。查当前占用：

sudo journalctl --disk-usage

输出：Archived and active journals take up 3.1G on disk.

处理分两步。先物理清理，立即生效：

sudo journalctl --vacuum-size=200M

这一步立刻释放约 2.9GB。然后做根治——限制以后的最大占用，编辑 /etc/systemd/journald.conf：

sudo vi /etc/systemd/journald.conf

找到并修改两行（去掉注释）：

SystemMaxUse=500M
MaxRetentionSec=2week

保存后重启服务：

sudo systemctl restart systemd-journald

这样以后 journal 最多占 500MB，且两周前的日志自动清理。这是第一个问题的根治。

四、第二刀：Docker 空间

Docker 吃掉的 8GB 里，最常见的构成是三类：悬空镜像、停止的容器层、构建缓存。逐个查：

docker system df

输出大致是：

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          18        3         5.2GB     4.1GB (78%)
Containers      9         3         410MB     380MB (92%)
Local Volumes   6         4         1.1GB     210MB
Build Cache     27        0         1.4GB     1.4GB

"RECLAIMABLE"就是可以安全回收的部分。一次性清理：

docker system prune -af --volumes

参数说明：-a 连同未被任何容器使用的镜像一起删；-f 跳过确认；--volumes 清理未使用的卷。这一步回收约 5.7GB。

有一个值得单独提醒的点：如果容器用的是匿名卷，--volumes 会把数据一起删掉。清理前先确认哪些卷在用：

docker volume ls -f dangling=true

确认列表里没有需要保留的（比如数据库卷），再执行 prune。我当时就是先把一个数据库容器停掉、卷单独备份出来之后才敢加 --volumes 的，这一步谨慎不亏。

清理完之后再设置一次根治：给 Docker 配置日志大小上限，防止容器日志失控（这是很多人忽略的，容器 stdout 日志默认也是无限增长）。编辑 /etc/docker/daemon.json：

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

重启 Docker 生效。已存在的容器不会自动套用新配置，需要重建才生效，这点官方文档写得清楚但实践中经常被漏掉。

五、第三刀：/root/dumps 目录

这个 6GB 的目录，查了一圈发现是几个月前排查一个 JVM 问题时的堆转储文件，问题解决后忘了删：

ls -lh /root/dumps/

三个 hprof 文件加起来 6GB。确认线上已无该问题后直接删除。这类"历史遗留"最难防——建议的对策是给所有手工创建的临时目录统一放 /tmp 或加个清理脚本，配合 crontab 定期清：

# 每周日凌晨清理超过 7 天的 /root/dumps 旧文件
0 3 * * 0 find /root/dumps -type f -mtime +7 -delete

六、收尾验证与监控加固

全部处理完后：

df -h

/dev/vda1  40G  21G  19G  52% /

从 98% 降到 52%，回收约 17GB。最后做两件防止复发的事。

第一，让 journald 和 Docker 的限制策略保持生效（前面已做），这是"根治"和"救火"的区别。

第二，把告警阈值细化。华为云的云监控默认磁盘告警一般是 90%，这次从 90% 到 98% 其实只隔了几个小时——空间增长是被日志刷的，速度很快。对策是在云监控里加两级告警：80% 提醒（邮件）、90% 紧急（短信），给处置留出时间窗。另外给根分区以外的挂载点也配上告警，别只盯系统盘。

七、复盘：这次为什么会被打爆

回头看，三个源头对应三种典型失误：

1. journald 未设上限——属于"默认配置不满足生产"的典型，装完系统就该改；
2. Docker 镜像与构建缓存堆积——CI/CD 流水线每次构建都留中间层，长期没人清；
3. 临时文件落在 /root 下——人工操作的随意性，没有机制兜底。

磁盘爆满很少是单一原因，几乎总是"多个增长源在没人看的地方各自膨胀"的合力。而治理思路也是一致的：先定位（du 逐层下钻），再分类处理（能删的删、该限的限），最后补监控和自动清理，把"人肉运维"换成机制。

本文所有命令均在 Ubuntu 22.04 上实际执行验证，其他发行版（CentOS 系）命令基本一致，journald 配置路径相同，Docker 配置通用。如果你的 ECS 也遇到过类似问题，欢迎评论区交流你的排查手法。