先确认磁盘空间与inode是否双满：用df -h看Use%、df -i看IUse%，再分层定位日志、临时文件、数据库文件或已删未释放的“僵尸文件”；重点排查systemd日志、数据库.ibd/pg_wal文件、/tmp缓存及lsof +L1发现的删除未释放文件。
直接看挂载点空间和 inode 是否双满，再分层定位是日志、临时文件、数据库文件还是已删未释放的“僵尸文件”在吃空间。
先确认是空间满还是 inode 满
运行两条命令并排对比：
- df -h：看各挂载点的 Use%。重点关注 /、/var、/data 等业务常用挂载点；
- df -i：看 IUse%。若某分区 df -h 显示 85%，但 df -i 显示 100%，说明小文件爆炸（如日志碎片、缓存目录下百万个 .tmp），此时删大文件没用，得清小文件目录；
- 注意：df 显示 Use% 超过 100%（如 102%）不一定是真满，可能是 ext4 预留块被临时抵扣或统计延迟，需结合业务是否报错综合判断。
快速定位占用最大的目录层级
进入疑似高负载挂载点（如 cd /var），执行：
- du -sh --max-depth=1 * 2>/dev/null | sort -hr：列出一级子目录大小，一眼看出 log、cache、lib 哪个最占空间；
- 对可疑目录继续钻取，比如 cd log && du -sh * | sort -hr | head -5；
- 查单个超大文件：find . -type f -size +100M -exec ls -lh {} \;，可加 -mtime +7 过滤旧文件避免误删活跃日志。
重点排查四类高频“空间刺客”
以下场景在生产环境占比超 70%：
- 系统日志膨胀：/var/log/journal（systemd 日志）、/var/log/syslog、/var/log/messages。journal 可用 journalctl --disk-usage 查大小，清理用 journalctl --vacuum-size=500M；
- 数据库文件暴增：MySQL 的 /var/lib/mysql/*.ibd、PostgreSQL 的 pg_wal/、MongoDB 的 data 目录。进库查大表（如 MySQL 执行 SELECT table_schema, table_name, round((data_length+index_length)/1024/1024,2) AS size_mb FROM information_schema.TABLES ORDER BY size_mb DESC LIMIT 5）；
- 临时与缓存堆积：/tmp 下残留的安装包、解压目录；/var/cache/apt/archives（Debian/Ubuntu）、/var/cache/yum（CentOS）里的旧包；Docker 的 docker system df 查镜像、容器、卷占用；
- 已删除但未释放的文件：执行 lsof +L1，输出中带 “deleted” 字样的文件就是元凶（常见于被 rm 但进程仍在写日志的 tomcat、nginx、mysql）。解决方式是重启对应服务，或 kill -USR1 触发日志重开（视服务支持而定）。
验证清理效果与预防建议
清理后别急着收工：
- 再次运行 df -h 和 du -sh /path/to/cleaned，确认差值收敛（理想情况差值
- 检查是否有服务因磁盘满异常退出（systemctl list-units --state=failed）；
- 配置基础防护：logrotate 定期轮转日志、数据库开启 binlog_expire_days、定期 apt clean 或 yum clean all、设置 crontab 清理 /tmp 旧文件（如 find /tmp -type f -mtime +7 -delete）。
