告别手动排查！用ncdu可视化分析CentOS目录占用（附Docker/Jenkins专项清理指南）

告别手动排查！用ncdu可视化分析CentOS目录占用（附Docker/Jenkins专项清理指南）

你是否也经历过这样的场景：服务器磁盘空间告急的警报突然响起，df -h显示根分区飘红，而你却像面对一个杂乱无章的黑箱，不知道从哪里下手？传统的du -sh * | sort -hr命令虽然强大，但在层层嵌套的目录森林里，它更像是一份没有地图的清单，你需要反复执行、逐级深入，过程枯燥且低效。对于现代开发环境，尤其是集成了Docker、Jenkins、Maven等工具的CentOS服务器，这种“盲人摸象”式的排查更是痛点频发——你知道空间被占用了，却很难快速锁定是哪个容器的日志在疯长，或是哪次失败的Jenkins构建留下了数GB的垃圾。

今天，我想分享一个能彻底改变你磁盘空间管理体验的工具：ncdu。它不是一个复杂的新系统，而是一个简单直接的命令行可视化工具，能让你像在图形界面中一样，直观地“看到”整个目录树的大小分布，并快速导航、定位问题根源。更重要的是，我将结合多年运维实战经验，为你梳理出针对Docker镜像层、Jenkins构建记录等特定“空间杀手”的专项清理策略与预防措施。这不仅仅是几个命令的罗列，更是一套从“被动救火”到“主动治理”的完整工作流优化思路。

1. 为什么你需要ncdu：告别命令行“盲扫”

在深入工具细节之前，我们不妨先对比一下传统方式与可视化分析的核心差异。当你使用du命令组合时，你得到的是类似下面的文本输出：

4.5G /var/lib/docker 2.1G /home/user/projects 1.8G /var/log ...

这份列表告诉你哪些目录大，但关系是缺失的。/var/lib/docker占了4.5G，但这4.5G具体由哪些子目录构成？是overlay2存储驱动占得多，还是containers下的日志文件？要回答这个问题，你必须再次执行du -sh /var/lib/docker/*，如果子目录依然庞大，这个过程还得重复。这种线性、迭代的排查方式，在时间紧迫的线上故障处理中显得格外笨重。

而ncdu (NCurses Disk Usage)的核心价值，就在于它提供了交互式、层次化的空间视图。启动后，它会先扫描指定目录，然后呈现一个基于文本的UI界面。在这个界面里，你可以：

• 按大小排序：最大的目录或文件永远排在最前面。
• 键盘导航：使用方向键在目录树中上下移动，按回车键进入子目录。
• 即时查看：在任意层级，都能清晰看到当前目录下各项目的尺寸贡献占比。
• 快速操作：可以直接标记文件/目录进行删除（需谨慎），而无需记忆复杂的rm命令路径。

这种工作流带来的效率提升是质的飞跃。你不再需要猜测和反复输入命令，而是像使用资源管理器一样，顺着“体积最大”这条线索，一路追查到底。对于DevOps工程师和系统管理员来说，这意味着能将宝贵的精力从繁琐的排查中解放出来，投入到更重要的架构优化和自动化脚本编写上。

1.1 安装与快速上手ncdu

在CentOS 7或8上安装ncdu非常简单，它通常包含在EPEL仓库中。

# 对于CentOS 7/RHEL 7 sudo yum install epel-release sudo yum install ncdu # 对于CentOS 8/RHEL 8，使用dnf sudo dnf install epel-release sudo dnf install ncdu

安装完成后，最基本的用法就是扫描你想分析的目录。例如，要分析根目录/，但排除掉/proc和/sys这些虚拟文件系统（它们会干扰扫描结果），可以运行：

sudo ncdu / --exclude /proc --exclude /sys

注意：使用sudo是为了确保能读取所有受权限保护的文件和目录，获得最准确的空间报告。首次扫描可能需要一些时间，取决于磁盘大小和文件数量。

扫描完成后，你会进入一个类似下图的交互界面（此处为文字描述）： 屏幕顶部会显示当前扫描路径和总大小。主体部分是一个列表，显示了当前目录下所有子目录和文件的大小，默认按从大到小排序。每个条目会显示其大小、占当前目录总大小的百分比，以及名称。你可以通过方向键选择条目，按Enter键进入该子目录，按d键标记该条目用于删除（再次按d取消标记），按i查看当前选中项目的详细信息。

一个非常实用的技巧是，在扫描时使用-x参数，这会让ncdu不跨越文件系统边界。例如，如果你只想分析挂载在/home的分区，而不想让它去统计/或其他挂载点，这个参数就非常关键：

sudo ncdu -x /home

2. 实战：用ncdu精准定位CentOS环境下的“空间大户”

掌握了ncdu的基本操作后，我们就可以针对典型的CentOS服务器环境，进行一场高效的“空间审计”。现代服务器，特别是用作开发、测试或CI/CD节点的，其磁盘占用往往有鲜明的模式。我们可以有的放矢地进行检查。

2.1 扫描策略与初步分析

启动ncdu后，不要急于深入某个目录。先在根目录层级进行宏观观察。执行sudo ncdu / --exclude /proc --exclude /sys，你会立刻看到如/var、/home、/usr这几个常客。我们的目标就是找出其中异常膨胀的那一个。

假设扫描结果显示：

• /var占用了 30G 中的 22G
• /home占用了 5G
• /usr占用了 3G

那么/var显然是首要嫌疑对象。按方向键选中/var，按Enter进入。

2.2 深入/var：揪出罪魁祸首

进入/var后，列表会刷新。在这个层级，你需要重点关注以下几个“高危”子目录：

在ncdu界面中，你会直观地看到这几个目录的大小。如果lib/docker显示为 15G，那么问题很可能就出在Docker上。同样，如果lib/jenkins异常庞大，Jenkins就是下一个需要深入的对象。

这种可视化逐层下钻的过程，比任何命令行组合都更直观、更不容易遗漏。你不需要记住复杂的路径，只需要跟着“最大块”的视觉线索走。

3. 专项清理指南：针对Docker的深度空间回收

当ncdu帮你锁定/var/lib/docker是元凶后，我们面临的就不再是“找问题”，而是“解决问题”。Docker的磁盘占用有其特殊性，粗暴地删除文件可能导致容器故障。因此，清理需要遵循一套安全且有效的流程。

3.1 理解Docker的磁盘占用构成

首先，用Docker自带的诊断命令建立一个整体认知：

sudo docker system df

这个命令的输出非常清晰，它会将占用分为四类：

• Images： 本地存储的镜像。
• Containers： 运行中及停止的容器所占用的可写层（R/W layer）。
• Local Volumes： 由Docker管理的命名卷和匿名卷。
• Build Cache： 镜像构建过程中产生的缓存。

提示：TYPE列显示了类型，TOTAL、ACTIVE、SIZE、RECLAIMABLE这几列是关键。RECLAIMABLE直白地告诉你有多少空间是可以安全回收的。

3.2 分级清理操作

我推荐一个从安全到激进的分级清理策略，你可以根据实际情况选择执行到哪一步。

第一级：基础安全清理这个命令会删除所有已停止的容器、所有未被使用的网络（dangling network）以及所有悬空镜像（dangling image，即没有标签且未被任何容器引用的中间层镜像）。这个操作非常安全，不会影响任何正在运行的容器及其依赖的镜像。

sudo docker system prune

系统会交互式地询问你是否继续，输入y确认。如果你想跳过确认，可以加上-f参数。

第二级：清理未使用的镜像如果你确定有些镜像虽然下载了，但近期甚至永远都不会再用（比如旧版本的测试镜像），可以清理所有未被任何容器引用的镜像。

sudo docker image prune -a

注意：-a参数意味着“所有未使用的镜像”，而不仅仅是悬空镜像。这会删除那些有明确标签（如myapp:v1.0）但当前没有任何容器（包括停止的）使用它的镜像。执行前请务必确认。

第三级：彻底清理（包含构建缓存和卷）这是最彻底的清理，适用于磁盘空间极度紧张，且你确信可以清理所有无用数据的环境。

sudo docker system prune -a --volumes

• -a: 删除所有未被使用的镜像和容器。
• --volumes:危险参数。它会删除所有未被任何容器引用的命名卷和匿名卷。如果卷里存有数据库文件等重要数据，且没有备份，将导致数据丢失。请务必谨慎。

3.3 治本之策：预防空间再次爆满

清理只是临时解决方案，建立预防机制才能一劳永逸。

1. 配置Docker日志驱动限制容器标准输出日志默认会无限增长，这是隐藏的“空间黑洞”。修改Docker守护进程配置来限制日志大小和数量。

sudo tee /etc/docker/daemon.json <<-'EOF' { "log-driver": "json-file", "log-opts": { "max-size": "10m", "max-file": "3" } } EOF sudo systemctl restart docker

此配置将每个容器的日志文件大小限制在10MB，最多保留3个文件（如container.log、container.log.1、container.log.2）。此配置仅对新创建的容器生效。

2. 设置定期清理Cron任务将安全清理动作自动化。例如，每周日凌晨3点执行一次基础清理：

# 编辑root用户的crontab sudo crontab -e # 在文件末尾添加一行 0 3 * * 0 /usr/bin/docker system prune -f

4. 专项清理指南：为Jenkins“瘦身”

Jenkins作为CI/CD的核心，其工作空间和构建记录是另一个主要的磁盘消耗源。通过ncdu定位到/var/lib/jenkins过大后，我们需要从界面配置和文件操作两方面入手。

4.1 在Jenkins界面中配置自动清理

这是最优雅、最自动化的方式。对于每个Jenkins任务（Job），都应该配置“丢弃旧的构建”。

1. 进入你的Jenkins任务配置页面。
2. 找到“丢弃旧的构建”(Discard old builds) 选项。
3. 启用它，并设置合理的策略。一个常见的策略是：
   • 保持构建的天数：例如 7
   • 保持构建的最大个数：例如 10
   • 高级选项：通常建议勾选“仅保留成功/稳定的构建日志”等，进一步节省空间。

这个策略意味着，无论构建多少次，Jenkins只会保留最近10次构建，或者7天内的构建，以先到者为准。旧的构建记录（包括控制台日志、归档制品等）会被自动删除。

4.2 手动清理文件系统

有时，一些失败的构建或异常任务可能会在工作空间留下巨大的残留文件，或者你需要立即回收空间。这时可以结合ncdu进行手动清理。

首先，用ncdu深入/var/lib/jenkins目录：

sudo ncdu /var/lib/jenkins

重点关注以下子目录：

• workspace/<job_name>: 每个任务的工作空间。检查是否有任务留下了巨大的编译产物、依赖包（如node_modules,target/）而未清理。
• jobs/<job_name>/builds/: 构建记录目录。即使配置了丢弃策略，也可能存在大量历史目录。
• caches/: Jenkins插件缓存。

在ncdu界面中，导航到异常大的目录。在删除前，请确保对应的Jenkins任务已停止。你可以使用ncdu的d键标记要删除的目录，然后按Shift + d执行删除。但更稳妥的做法是退出ncdu，使用rm命令进行精确删除。

例如，清理某个特定任务的陈旧构建记录：

# 请务必将 <job_name> 替换为实际的任务名，并谨慎操作 sudo rm -rf /var/lib/jenkins/jobs/<job_name>/builds/<old_build_number>/

清理所有任务的node_modules缓存（假设工作空间在默认位置）：

# 这是一个查找命令，先查看有哪些大的node_modules sudo find /var/lib/jenkins/workspace -name "node_modules" -type d -exec du -sh {} \; | sort -hr # 确认无误后，可以删除（风险自担） # sudo find /var/lib/jenkins/workspace -name "node_modules" -type d -exec rm -rf {} \;

4.3 清理其他常见缓存

除了Docker和Jenkins，开发环境中还有其他缓存目录需要关注。在ncdu的全局视图中，你可能会发现/home或/root目录下的缓存。

• Maven本地仓库：通常位于~/.m2/repository/。可以定期清理_remote.repositories和*.lastUpdated等失败下载的残留文件，但对于正式依赖，建议通过Maven插件（如mvn dependency:purge-local-repository）或在IDE中管理，避免手动删除导致构建失败。
• npm缓存：运行npm cache clean --force或直接删除~/.npm/_cacache目录。
• 系统包管理器缓存：对于YUM/DNF，可以运行sudo yum clean all或sudo dnf clean all来清理下载的包文件。这些缓存在你确定短期内不会重装大量软件包时是可以清理的。

最后，别忘了/var/log。使用logrotate服务是管理日志的标准做法。你可以检查/etc/logrotate.conf及其/etc/logrotate.d/下的子配置，确保关键服务（如nginx, docker, jenkins）的日志轮转配置是生效的。对于已经过大的历史日志文件（如*.log.1,*.gz），可以在确认无用后手动删除。

将ncdu融入你的日常巡检流程，结合这些有针对性的清理和预防策略，你就能建立起对服务器磁盘空间的清晰掌控感。从被动的警报响应，转变为主动的空间治理，这正是高效运维的体现。