Linux服务器磁盘突然被占满？小心是Docker在“吃”空间！手把手教你用ncdu排查和清理
Linux服务器磁盘突然被占满？小心是Docker在"吃"空间！手把手教你用ncdu排查和清理
那天早上，当我像往常一样登录开发服务器准备部署新版本时，终端里刺眼的红色警告让我瞬间清醒——/dev/sda6 100% used。作为一个常年与Docker打交道的开发者，我立刻意识到这很可能又是那些"隐形空间吞噬者"在作祟。Docker确实极大简化了我们的开发流程，但如果不了解它的存储机制，很容易就会陷入磁盘空间莫名消失的困境。
这次经历让我决定系统性地梳理Docker空间占用问题。与网上大多数泛泛而谈的"Linux磁盘清理"教程不同，本文将聚焦Docker特有的存储机制，特别是aufs/overlay2存储驱动下那些容易被忽视的空间占用点。我们会使用ncdu这款神器进行深度空间分析，并探讨从粗暴清理到精细管理的全套解决方案。
1. 为什么Docker会成为磁盘空间的"隐形杀手"？
很多开发者第一次遇到Docker占用磁盘空间时都会感到困惑——明明容器运行得好好的，为什么主机磁盘会突然告急？这需要从Docker的存储架构说起。
Docker使用分层存储机制，每个镜像和容器都由多个只读层叠加组成。当我们执行docker pull或docker build时，这些层会被下载并存储在/var/lib/docker目录下。问题在于，Docker默认不会自动清理这些资源，导致以下几种常见情况：
- 废弃的镜像层：每次构建新镜像都会产生新层，旧层不会被自动删除
- 停止的容器：即使容器已停止，其写入层仍然占用空间
- 构建缓存：Docker构建过程中的中间缓存会持续累积
- 容器日志：默认情况下，容器日志会无限增长
更棘手的是，使用传统的du命令很难直观地发现这些问题。因为Docker的存储驱动（如aufs/overlay2）会通过联合挂载的方式呈现文件系统，导致在普通目录下查看的大小与实际磁盘占用不一致。
2. 诊断利器：ncdu深度使用指南
当面对"磁盘已满"的紧急情况时，我们需要一款比传统du更高效的工具。ncdu(NCurses Disk Usage)就是为此而生——它不仅能快速扫描磁盘使用情况，还提供了交互式界面帮助定位问题。
2.1 安装与基本操作
在基于Debian的系统上安装：
sudo apt update && sudo apt install ncdu -y对于RHEL/CentOS系统：
sudo yum install ncdu -y基本扫描命令：
sudo ncdu / # 扫描整个根目录扫描完成后，你会看到一个交互式界面，以下是最常用的操作键：
| 按键 | 功能描述 |
|---|---|
| ↑/↓ | 上下移动光标 |
| →/Enter | 进入选中目录 |
| ← | 返回上级目录 |
| n | 按文件名排序 |
| s | 按大小排序 |
| d | 删除选中项 |
| g | 切换百分比显示模式 |
2.2 定位Docker存储热点
针对Docker问题，我们需要重点关注/var/lib/docker目录：
sudo ncdu /var/lib/docker典型的问题目录结构可能如下：
/var/lib/docker ├── overlay2 # 存储驱动目录，占用最大 │ ├── 0123456789abcdef... # 镜像层哈希目录 │ └── ... ├── containers # 容器相关数据 │ ├── abcdef... # 容器ID目录 │ │ └── abcdef...-json.log # 容器日志文件 │ └── ... └── volumes # 数据卷 ├── _data # 卷数据 └── ...在实际案例中，我曾发现一个生产环境的overlay2目录占用了近80GB空间，其中大部分是数月积累的旧镜像层和停止的容器。
3. 精准清理策略：从安全到彻底
找到问题所在后，我们需要根据实际情况选择清理策略。以下是按照风险从低到高排列的解决方案：
3.1 安全清理：日志与缓存
清理容器日志（不影响运行中的容器）：
# 查看日志文件大小 sudo find /var/lib/docker/containers -name "*-json.log" -exec ls -lh {} \; # 清空所有容器日志 sudo sh -c 'truncate -s 0 /var/lib/docker/containers/*/*-json.log'清理构建缓存：
docker builder prune3.2 中级清理：未使用资源
使用docker system prune清理孤立资源：
# 查看将被删除的内容（模拟运行） docker system prune --dry-run # 实际执行清理 docker system prune -f这个命令会删除：
- 所有停止的容器
- 不被任何容器使用的网络
- 悬空镜像（未被任何容器引用的镜像）
- 构建缓存
3.3 彻底清理：重置Docker存储
当需要彻底清理时（注意：这将删除所有Docker数据！）：
# 停止Docker服务 sudo systemctl stop docker # 删除Docker存储目录 sudo rm -rf /var/lib/docker/* # 重启Docker sudo systemctl start docker警告：此操作会删除所有镜像、容器和卷！仅在所有容器都可以重建时使用。
4. 预防胜于治疗：Docker存储管理最佳实践
清理只是治标，建立良好的存储管理习惯才能治本。以下是我总结的几条关键实践：
4.1 定期维护策略
建议将以下命令加入cron定期执行：
# 每周清理一次未使用资源 docker system prune -f # 每月清理一次构建缓存 docker builder prune -af4.2 日志管理配置
在/etc/docker/daemon.json中配置日志轮转：
{ "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } }4.3 存储驱动选择
不同存储驱动的空间效率对比：
| 驱动类型 | 空间效率 | 性能 | 稳定性 |
|---|---|---|---|
| overlay2 | 高 | 高 | 高 |
| aufs | 中 | 中 | 高 |
| devicemapper | 低 | 低 | 中 |
推荐使用overlay2作为生产环境存储驱动，可通过以下命令检查当前驱动：
docker info | grep "Storage Driver"4.4 镜像构建优化
减少镜像层数是节省空间的关键：
# 不好的实践 - 每个RUN创建新层 RUN apt update RUN apt install -y package1 RUN apt install -y package2 RUN apt clean # 好的实践 - 合并命令减少层数 RUN apt update && \ apt install -y package1 package2 && \ apt clean5. 高级技巧：当标准方法不够用时
在某些极端情况下，即使执行了上述所有清理操作，磁盘空间仍然异常。这时可能需要考虑以下高级排查手段：
5.1 查找被删除但仍被进程占用的文件
# 查找已删除但未释放的大文件 sudo lsof | grep deleted | sort -nk7 | tail5.2 检查文件系统错误
# 卸载文件系统 sudo umount /dev/sda6 # 检查并修复 sudo fsck -y /dev/sda65.3 调整Docker存储位置
如果根分区空间有限，可以考虑将Docker存储迁移到其他分区：
# 停止Docker服务 sudo systemctl stop docker # 迁移数据 sudo rsync -avz /var/lib/docker /mnt/big_disk/ # 修改Docker配置 sudo vim /etc/docker/daemon.json添加以下内容：
{ "data-root": "/mnt/big_disk/docker" }最后重启Docker服务：
sudo systemctl start docker那次磁盘爆满事件后，我在所有服务器上都设置了监控告警，当/var/lib/docker超过特定阈值时立即通知。同时，我也养成了定期检查Docker存储使用情况的习惯——毕竟在运维领域，预防性维护永远比紧急救火来得高效。