面对 100TB+ 超大规模目录,使用 gdu 必须优先考虑扫描性能、内存占用和操作安全性,避免误删或扫描导致系统负载过高。以下是分阶段的最佳实践方案,兼顾效率与安全。
一、风险控制与准备(操作前必做)
1. 用 screen/tmux 防止终端断开
100TB 扫描可能耗时数小时,务必用终端复用工具避免操作中断:
| |
如果意外断开,用 screen -r gdu-cleanup 或 tmux a -t gdu-cleanup 重新连接。
2. 先导出扫描结果备份(关键!)
在删除前先导出 JSON 报告,万一误删可回溯目录结构:
| |
用 tail -f /workspace/gdu_scan.log 查看扫描进度。
二、高效扫描:分层次定位大文件(避免一次性扫100TB)
100TB 目录直接全量扫描会导致内存飙升、耗时过长,建议分层扫描+精准定位。
1. 第一步:先看「顶层目录概览」
用 --depth 限制扫描深度,快速找到最大的子目录:
| |
输出示例:假设发现 /workspace/ckpt_downstream/zzm/old_experiments 占 80TB,优先处理它。
2. 第二步:针对大子目录深入扫描
对定位到的大子目录单独扫描,同时开启低内存模式(避免 OOM):
| |
参数说明:
-g:恒定 GC 策略,降低 30% 内存占用;GOGC=50:进一步收紧内存管理(默认 100),适合超大目录;-H:跳过.git、.cache等隐藏目录(如需要可去掉)。
3. 第三步:非交互模式快速揪出「TOP 50 大文件」
如果目录结构复杂,直接用非交互模式列出最大的文件,优先清理:
| |
三、安全删除:避免误删的核心操作
100TB 数据误删恢复极难,务必遵循「先确认、再移动、最后删除」的流程。
1. 交互模式下的安全操作步骤
进入 gdu 交互界面后:
预览文件内容:选中文件按
v,确认是无用文件(如旧 checkpoint、日志);先移动到「待删临时目录」(替代直接删除):
1 2 3 4 5# 在 gdu 外先创建临时目录 mkdir -p /workspace/zzm_to_delete # 在 gdu 中记住要删的文件路径,退出后用 mv 移动(更安全) mv /workspace/ckpt_downstream/zzm/old_experiments/exp1.ckpt /workspace/zzm_to_delete/观察业务无影响后,再批量删除临时目录:
1 2# 确认24小时后业务正常,再执行删除 rm -rf /workspace/zzm_to_delete/*
2. 必须避免的「高危操作」
❌ 不要在 gdu 中直接按
d删除 100GB+ 的大文件(先移动确认);❌ 不要用
gdu -x /扫描整个系统(专注你的工作目录);❌ 删除前务必用
lsof检查文件是否被进程占用:1 2# 检查大文件是否被占用(替换为你的文件路径) lsof /workspace/ckpt_downstream/zzm/old_experiments/exp1.ckpt如果有输出,说明文件被占用,需先停止对应进程再删除,否则空间不会释放。
四、性能优化:让100TB扫描更快
1. 排除无用目录
如果你的目录下有 .git、node_modules、__pycache__ 等无需扫描的目录,用 -i 排除:
| |
2. 分批扫描(极端情况)
如果单目录文件数超千万,可拆分成多个子目录分批扫描:
| |
五、收尾验证:确认空间释放
删除完成后,用以下命令验证空间是否真正释放:
| |
总结:100TB+ 目录清理的「黄金流程」
- 准备:
screen保活 + 导出 JSON 备份; - 定位:分层扫描 + TOP 文件列表,优先找最大的子目录/文件;
- 删除:先移动到临时目录 → 观察业务 → 最终批量删除;
- 验证:
df -h确认空间释放。
需要我帮你生成一份可直接执行的分步脚本,把上述流程自动化吗?
张芷铭的个人博客
Comments