1. “rea”到底是什么一台挤爆的开发机逼出的资源普查工具先说结论我再解释为什么。你看到的“rea”是我自己在一台快被日志、容器镜像和缓存文件塞满的台式机上临时写出来的一个资源普查命令集合。它不是某个毛坯界面也不是什么商用产品更不是一段只在演示环境里能跑通的演示脚本——”rea“就是Reduce Everything Approach什么都瘦身三个单词的首字母缩写本质是一组把 disk、memory、CPU 和 container 四类资源一次性盘清楚的 Bash 脚本。为什么会有它上个月我碰上一台开发机磁盘使用率到了 94%每次docker build之后系统就卡到几乎没法敲命令。我一开始以为是内存不够结果free -h一看还有 12G 空闲以为是某个服务把 CPU 吃满了top排序好几轮也没发现异常。最后打开 NCDU 才发现问题的元凶是/var/lib/docker/overlay2和~/Library/Caches下面堆了几百 GB 的陈旧文件。那台机器系统变慢根本原因是磁盘到了临界线页面文件、临时目录和日志服务在这个状态下疯狂争抢 IO。刚听到“rea”这个名字的人通常第一反应是这是不是某个新框架或者是某种运行时环境我干脆把话说清楚它不是也无意成为大而全的监控平台。它解决的是每个搞开发的人都绕不开的那类“破事”——磁盘突然告警、容器镜像占满空间、journalctl日志体积爆炸、缓存目录一个比一个大。要是在生产环境你一般会有完善的 Prometheus 告警和 Grafana 面板但本地开发机呢基本上就是“等卡到受不了了才手动清理”的状态。这个工具适合谁三种人最需要它一是经常在本机起 Docker Compose 做测试的开发者镜像和构建缓存消耗量极大二是做前端或者移动端构建的人node_modules和各类缓存动不动就是几十 GB三是有多台 Linux 或 macOS 机器平时不想一一登录上去执行命令的运维和效率控。它没有守护进程、没有服务端、没有数据上报就是几个脚本拷过去就能用跑完就在终端里把结果列清楚清理动作由你自己决定而不是由某个工具擅自删文件。从设计思路上说我一开始也想图省事直接用现成的 Batocera 之类的工具。但用了一圈发现大部分图形化磁盘分析工具只解决“看”的问题不会把内存、CPU 和容器空间统一汇总更不会在同一个输出里给出“可操作建议”。我不想要一个只会画方块的工具我想要的是**一次命令之后能直接告诉我‘谁该清、谁必须留着、清完能省多少空间’**的诊断结果。这就是我把 rea 设计成“四维普查 定向清理建议”的原因。2. Rea 的设计逻辑与三个核心原则写 rea 之前我给自己定了三条死规矩这三条规矩后来也被证明是这套脚本能落地、能传播、能长期用下去的根本原因。第一只读优先清理必须显式化。默认执行rea的时候脚本只做扫描、统计和展示不删任何东西。所有涉及删除或停用容器的操作都必须额外加--clean之类的后缀参数。这么设计的理由很简单自动删除太危险。尤其是 Docker 的孤儿卷和 build cache有些数据可能是某个还没提交到远端仓库的中间结果删了就得重新跑一遍。我宁可多打一个参数也不想在凌晨三点误删数据。第二视图分离扫描与解读分开。rea默认输出的是一个简明的总览表只会列出排名靠前的几个隐患点免得输出上百行把人淹没加上-vverbose之后才会打印每个进程的详细信息、每个缓存目录的明细和每个容器的状态。这个设计是从一个真实蠢坑里学来的。早期版本我试过一次性把所有信息都打出来结果终端滚了几百行真正要紧的内容反而被淹没在里面。现在默认输出只显示 25 行以内的摘要用户想看细节再手动打开。第三跨平台命名一致行为有差异。macOS 和 Linux 在命令细节上有很多不兼容的地方比如du在 macOS 上是-sh部分 Linux 发行版则需要配合--block-size使用再比如内存信息Linux 可以直接读/proc/meminfomacOS 就需要用vm_stat。rea 在内部做了一层薄薄的封装把平台差异全部吸收掉但对使用者的命令入口完全统一。换句话说Linux 和 macOS 上打出的是同一个rea命令行为一致。这三个原则看上去都是最简单朴素的工程判断但恰恰是它们保证了脚本的鲁棒性。下面我会把四个模块Disk、Memory、CPU、Docker一一拆开讲一下每个模块具体做了什么以及里面有什么值得抄走的经验。3. 四维盘点拆解磁盘、内存、CPU 与容器的扫描实现3.1 磁盘模块不只查磁盘满了还定位“谁吃掉了空间”磁盘模块不复杂但里面有一个关键细节扫描深度和排序策略。rea disk默认执行三步操作用df -h拿到所有挂载点的使用率过滤掉tmpfs、devtmpfs这类虚拟文件系统只剩对业务有实际影响的真实分区。对/var/lib/docker、~/Library/Caches、~/.cache、/tmp、$HOME下的常用缓存目录做du -sh扫描按人可读格式排序列出 Top 20 大目录。输出后备注清理建议。这一步是纯规则的比如/var/lib/docker超过 30G就提示“建议运行 docker system prune”~/.npm或yarn缓存超过 5G就提示“可以用 npm cache clean --force”。为什么要把缓存目录单独扫一遍而不是像 NCDU 那样全盘展开因为全盘展开的树形扫描虽然信息全但输出噪音太多。在一个正常开发机上/usr和系统目录加起来动辄几十万个文件你真正该关心的是几个体积膨胀到恶性的目录。rea 直接从已知的“嫌疑犯”开始查秒级出结果。为了查得更快我在脚本里对每个目标目录限定了timeout 30如果扫描超时就跳过并在结果里标记 SKIP避免某些目录因为特殊的文件系统挂载问题把整个命令卡死。check_dir_size() { local dir$1 local limit$2 if [ -d $dir ]; then local size size$(du -sh $dir 2/dev/null | cut -f1) echo -n $dir $size if [ -n $limit ]; ]; then # 简单比较大小超过 limit 时输出 WARN ... fi fi }这段代码是示意性的真实脚本里我把每个目录的大小阈值都做成了数组未来维护起来很方便。顺带提一句du在一些并行文件系统上跑会比较慢如果第一次运行觉得卡可以把--max-depth1改成--max-depth0减少一层目录展开。3.2 内存模块从/proc/meminfo和vm_stat里挖出真实压力内存模块的核心是判断“我这台机器究竟是内存不够还是缓存占用过多”。在 Linux 上我读取的是/proc/meminfo这个文件虽然年代久远但到今天依然是信息量最大的内存真相来源。关键字段有三个MemAvailable直接反映可用内存量不用自己减Cached显示文件缓存占了多少SwapTotal和SwapFree的组合能看出有没有swap颠簸现象。macOS 侧则读vm_stat单位是页page需要乘以页面大小才能换算成字节命令行里执行vm_stat的时候通常会带有page size of 4096 bytes这行提示。脚本里我会先sysctl hw.pagesize拿到实际的页大小再依次计算Pages free、Pages inactive、Pages active和Pages wired。很多开发者只看“可用内存 8G”“空闲内存 6G”就说内存没问题其实这是个常见误区。Linux 的 Cached 内存是内核主动用于加速读文件的缓存在内存有压力时会被回收复用不应该当作浪费但Pages wired或不可回收内核内存积累太多那才是真的占着不放。rea 在输出时会把这两类分开一类是“可以回收的缓存”一类是“不可回收的真实占用”这样排错时就能立刻判断是否需要加 SWAP 或减少并行任务数。if [ -f /proc/meminfo ]; then MemAvailable$(awk /MemAvailable/ {print $2} /proc/meminfo) SwapTotal$(awk /SwapTotal/ {print $2} /proc/meminfo) SwapFree$(awk /SwapFree/ {print $2} /proc/meminfo) fi如果 SwapTotal 虽然是 0但 MemAvailable 已经低于 1G脚本会输出强警告还有个比较实用的扩展配合pidstat或者/proc/*/status去查具体进程的VmRSS /proc/[pid]/status里每个进程的 VmRSS 一加就是整机物理内存使用量的近似视图。rea 里我用了ps -eo pid,rss,comm --sort-rss | head -20来拿前 20 个内存大户抓住了 RSS 破 GB 的进程内存问题基本就可以定位了。3.3 CPU 模块用“平均负载拐点”识别真正的瓶颈而不是只看百分比CPU 的部分我强调一个反直觉的判断方式——不要只看top里的 CPU 使用率数字。很多朋友在遇到卡顿时看到top里某进程 CPU 90% 就以为是它把机器弄卡的但实际情况往往是机器慢是因为磁盘 IO 瓶颈CPU 使用率虚高只是因为进程在不停重试或者忙着等待 IO 完成。真正要找的是平均负载Load Average在短时间内出现明显拐点。rea 的 CPU 模块会读取/proc/loadavg或uptime把 1 分钟、5 分钟、15 分钟的负载值打印出来并与 CPU 核数做对比。比如一台 8 核机器如果 1 分钟负载是 12而 15 分钟负载只有 3说明刚刚有一波突发任务把系统拖住了如果 15 分钟负载长期大于 8说明这台机器持续超载不是一瞬间的事。然后它才会去展示进程 CPU 排名。这里有个更容易踩的坑ps -eo pcpu显示的 CPU% 是进程生存周期内的平均值而不是瞬时的瞬间值。对于刚启动的高消耗进程这个百分比会被严重稀释而对于一个已经运行了 7 天的常驻进程哪怕它最近把 CPU 吃满了平均出来也只有 5%。所以 rea 不是只靠ps拿一次快照而是用top -b -n 1 -o %CPU这样的批处理模式拿到瞬时 CPU 占用用瞬时值排序后再结合负载数值做判断。# 获取瞬时 CPU 占用 Top 15 top -b -n 1 -o %CPU | sed -n 8,22p为什么选top -b -n 1“-b是 batch 模式不在交互界面里卡住“-n 1”只跑一轮秒退“-o %CPU”按 CPU 使用率排序。三个参数组合起来就是脚本脚本化获取瞬时 CPU 消耗的标准答案。3.4 容器模块把镜像、容器、卷和构建缓存全都暴露出来容器模块是这台机器能“起死回生”的关键。日常开发积累下来的 Docker 对象体积膨胀速度远超过想象。rea 容器模块用docker system df作核心再补上docker ps -a --size来展示每个容器的可写层大小。docker system df是一个被低估的命令单条命令就能看到镜像、容器、本地卷、构建缓存四类对象分别占了多少空间以及有多少处于“可回收”状态。后面再配上-vverbose参数时脚本才会跑docker images --format列出每个镜像的 ID、仓库名、创建时间和体积按占用从大到小排序。容器模块还有个“安全删除”设计rea docker --clean会依次执行docker container prune -f先清理停止的容器然后docker image prune -f清理无用镜像最后docker builder prune -f清构建缓存。为什么是这个顺序因为容器如果在运行引用的镜像就不能删先停容器再删镜像最后清构建缓存逻辑顺序最顺。这里绝不默认加--volumes来清理卷因为卷里经常埋着数据库数据是本地开发的高危数据区。docker_prune() { echo [1/3] 清理停止容器... docker container prune -f echo [2/3] 清理悬空镜像... docker image prune -f echo [3/3] 清理构建缓存... docker builder prune -f }运行完一套清理后rea 会再次调用docker system df对比清理前后的空间差。这一步很重要给人“做减法后的即时反馈感”。我看到过不少同事清理完 Docker 之后没有对比数据无法量化成果过两天又会忘记这回事。加一个前后对比的输出养成定期清理的习惯就容易多了。4. 实际运行效果与实际使用中容易忽视的细节我拿自己那台 512G SSD 的开发机来举个可复现的例子。跑rea disk第一次扫描的结果是这样的挂载点 / 使用率 74% 剩余可用 98G /Docker 镜像仓库目录 138G WARN 超过 30G ~/.cache 42G WARN 超过 5G ~/Library/Caches 38G WARN 超过 5G看问题一上来就暴露了。以前用df -h看到 74% 使用率时我并没有很着急以为一切正常但其实 Docker 相关目录和缓存已经吃掉了 200G 空间。紧接着我执行了rea docker --clean清理的动作很快五分钟左右就完成再去调用rea disk挂载点 / 使用率 51% 剩余可用 171G Docker 镜像仓库目录 44G OK 在阈值内 ~/.cache 22G OK 在阈值内 ~/Library/Caches 15G OK 在阈值内清理出整整 73G 空间。这对于没加磁盘的物理机来说等于多出来一个空闲盘。上面这个案例里有个细节是很多人会忽略的~/Library/Caches和~/.cache里面的数据可能是某些 IDE 索引、模拟器镜像或者浏览器缓存真的不能无脑全删。rea 给出的阈值策略是超过限值才建议清理并且清理指定目录不碰其它位置。执行rea cache --clean时脚本也只对这个目录下可以安全重建的缓存下手用户自己生成的配置类缓存被排除在删除列表之外。4.1 进程扫描时被误判的“内存大户”我第一次跑rea mem时输出里前两名是虚拟机进程和一个 IDE 的索引服务加起来消耗 6G 多。按直觉这俩是怀疑对象。但脚本分析进程的启动时间和持续活跃度后发现它们设定的是固定常驻内存兴奋属于正常资源占用并不能算泄漏。真正的问题反而是它们触发的一连串文件变更事件让某个后台同步服务频繁重启和写日志在 30 分钟时间里产生了 4G 的日志文件这才是磁盘满的直接导火索。所以我后来给 rea 额外加了一个journal扫描模块专门扫/var/log和~/Library/Logs下最近 7 天有改动的日志文件。这个优化很实用。排查性能问题不能只看资源占用最高的进程还要看“谁让别的进程变高”。4.2 在 macOS 上的兼容性问题rea 在 macOS 和 Linux 上的输出结构一致但脚本内部有不少条件分支。最典型的是du -sh在 macOS 默认输出的单位用的是 1024 进制Linux 则可能用 1000 进制如果拿数值直接和阈值比较会造成误判。我的解法是在脚本开头定义一个BYTES变量用du -sk拿到固定的 1024 字节粒度再统一换算不依赖不同系统默认单位的差异。另一个差异点macOS 上默认没有/proc/meminfovm_stat的页面大小不一定都是 4096所以要动态获取。真实的脚本里平台判断写在最前面把记忆、磁盘、容器三个模块各自需要的基础参数全准备好后面的逻辑只用统一变量不用再反复判断系统。case $(uname -s) in Linux) MEM_AVAILABLE$(awk /MemAvailable/ {print $2} /proc/meminfo) ;; Darwin) PAGE_SIZE$(sysctl hw.pagesize | awk {print $2}) MEM_AVAILABLE$(vm_stat | awk ...) ;; esac这就是跨平台脚本很土但很稳的写法。uname -s分支把差异在一开始就吸收掉后面干干净净。5. 自动化定时与脚本扩展把“急修”变成“常备”如果说前面四章是“工具能做什么”的功能部分那这一章是更值钱的经验怎么把一个只会在出问题时想起的工具变成能主动发现苗头的“哨兵”。rea 在设计时没有做成常驻守护进程但提供了建议级的 cron 配置。原样照搬一个 crontab 条目是这样0 9 * * 1 /usr/local/bin/rea disk --cron /tmp/rea_disk_report.txt 21 0 */4 * * * /usr/local/bin/rea docker --check /tmp/rea_docker_report.txt 21周一早上 9 点跑一次磁盘扫描每 4 小时检查一次 Docker 空间。这样时刻都在心里有数而不是等到某天 CI 突然因为磁盘空间不足失败才去救火。如果想把 rea 变成一个信息聚合的入口还可以利用它的定位特性把输出喂给 shell 别名或者你自己的监控脚本。比如我实际的做法是配合 macOS 的shortcuts命令在每天午休时弹一个通知报告磁盘剩余空间和 Docker 镜像总量。Linux 用户则可以做一个 systemd timer把报告发送到内部的消息频道。这样就把“本地普查工具”变成了团队的信息源之一。另外rea 的输出格式我特意设计成了“人类可读 机器可解析”的双模式默认输出带颜色和缩进方便人看加上--json参数时每条结果都变成结构化的 JSON 输出可以像 API 一样被后续脚本消费。这样一来同事以后写一个跨机器的汇总面板时不用重新发明轮子直接把每台机器的 JSON 汇总起来就行。我认为这是 rea 比多数一次性脚本多走了一步的地方。6. 用 rea 的体会与继续优化的方向如果你问我搞这个工具收获最大的是什么我可能会说把它从“一套救命脚本”慢慢完善成“一套方法论”的过程比脚本本身更有意思。回过头来复盘rea 这类工具存在的一个普遍问题在于默认安全策略与高频使用天然有冲突。因为它坚持“清理必须显式”很多同事拿过来后用了一次发现没有立刻看到空间数字下降就不愿意再用了他们预期是“我把命令跑一下工具就该自动给我腾出空间”。这个矛盾我目前还没完全解决解决方案是在输出里增加一行“当前可安全回收空间预估”把清理收益前置展示出来让人先看到甜头再决定要不要真正动手。这个优化已经在做了。另一条优化方向是让磁盘扫描支持 exFAT 或者网络挂载卷。现在du在 NFS 上会异常慢rea 在碰到这类挂载时就直接跳过了但那些目录反而往往是团队共享文件的堆积地体积可能不小。等有预算再尝试用find -mtime增量统计配合缓存结果用上次的扫描结果做差分极大缩短扫描耗时这个思路目前还在设计阶段。最后想对打算自己动手写类似工具的同行提一个建议先从一个真实的、让你肉疼的问题出发再把一个个小脚本合成一个统一接口。不要一开始就想着做完整平台。我以前用过的很多监控工具就是因为想做得太全最后连维护成本都覆盖不了价值。像 rea 这样二十来个核心函数加起来不过几百行脚本但每一个函数都是被真实问题“逼”出来的这才是它能长期用下去的根本原因。如果你也有类似的本地环境管理痛点照着这个思路去做。不需要用太重的框架不需要引入一整套监控体系从一条du命令开始一点一点把场景补齐起来你也能拥有一套属于你的“rea”。