linux磁盘空间告警时应先定位真实瓶颈：用du逐层下钻查大目录，lsof+L1揪出已删除但被占用的“幽灵文件”，df-th识别tmpfs/overlay等伪文件系统干扰，再重点清理journalctl日志、docker残留和包管理缓存。
Linux磁盘空间告警时，别急着删文件，先定位真实瓶颈——90%的问题出在“看不见”的地方：大日志、已删除但未释放的文件、隐藏挂载点或容器残留数据。
快速定位谁占了最多空间
用 du 结合 sort 和 head 逐层下钻，避免卡在海量小文件上：
- du -sh /* 2>/dev/NULL | sort -hr | head -10 —— 查看根下各一级目录大小（跳过权限错误）
- du -sh /var/* 2>/dev/null | sort -hr | head -5 —— 进入可疑目录继续深挖，如
/var/log、/var/lib - 加 –max-depth=1 防止递归过深拖慢速度；-x 参数可限制在同一文件系统内（避开挂载子目录干扰）
揪出“看不见”的大文件：已删除但仍被进程占用
文件被 rm 后若仍有进程打开它，磁盘空间不会释放。这类“幽灵占用”常导致 df 显示满，但 du 算不出来源：
- lsof +L1 —— 直接列出所有已删除但仍被打开的文件（需 root 权限）
- lsof | grep deleted | awk ‘{print $7,$9}’ | sort -nr | head -5 —— 按大小倒序看前5个（第七列是大小，第九列是路径）
- 常见场景：应用日志被轮转删除，但服务没重载日志配置，旧句柄仍持有大文件；解决办法是重启对应进程或用
kill -USR1触发日志重载（如 nginx、rsyslog）
检查挂载异常与伪文件系统干扰
df -h 显示满，但 du 总和远小于它？可能是挂载覆盖、tmpfs 占用或 overlayfs 留下的容器层：
- df -Th —— 加
-T看文件系统类型，重点关注tmpfs、overlay、shm等内存型或容器相关类型 - findmnt 或 mount | grep -E ‘(overlay|docker|kubepods)’ —— 快速识别容器运行时挂载点
- du -sh /var/lib/docker/overlay2/*/diff 2>/dev/null | sort -hr | head -3 —— Docker 用户重点查镜像层差异目录
日志与缓存：最常被忽略的“空间黑洞”
系统和服务默认日志策略宽松，长期不清理极易撑爆磁盘：
- journalctl –disk-usage —— 查 systemd 日志当前占用；用
--vacuum-size=100M或--vacuum-time=2weeks清理 - ls -lSh /var/log/*.log* | head -5 —— 找最大的原始日志；配合
logrotate配置检查是否生效（/etc/logrotate.d/） - apt clean（debian/ubuntu）或 yum clean all（RHEL/centos）—— 清理包管理器缓存，常省下几百MB到几GB
基本上就这些。核心逻辑是：先看 df 定范围，再用 du 找目录，结合 lsof 排“幽灵”，最后盯住日志、容器、缓存三类高频元凶。熟练后，5分钟内完成排查很常见。