根目录被日志撑满需分三步排查：先用df -h和df -i确认是空间满还是inode耗尽；再聚焦/var/log、/var/log/journal、/var/lib/mysql三大高危目录；最后用ls -lhs、journalctl --disk-usage、find等命令精准定位大日志文件，并检查是否被进程占用或有业务依赖。
根目录被日志撑满是最常见的爆满原因，但不能一删了之——得先确认是哪些日志、为什么暴涨、是否还在被进程写入。排查要分三步走：看整体、钻目录、盯文件。
第一步：确认是不是空间真满了，还是 inode 耗尽
执行两条命令，缺一不可：
- df -h：看 / 的 Use% 是否达到 100% 或接近（比如 98%+）；
- df -i /：如果空间还有余量但系统报 “No space left on device”，而这里 Use% 是 100%，说明是大量小文件占满 inode，不是日志文件大，而是数量太多（比如 /var/log/journal 下堆积了几十万条二进制日志条目）。
只有 df -h 显示空间满，且 df -i 正常（Use% 远低于 100%），才继续按“大日志文件”方向排查。
第二步：定位日志所在的高危目录
日志最常藏在三个地方，按优先级检查：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- /var/log：传统文本日志主阵地，如 messages、secure、kern、yum.log、nginx/access.log 等；
- /var/log/journal：systemd-journald 的持久化日志，默认启用后可能无声无息涨到几十 GB；
- /var/lib/mysql：MySQL 的 slow.log、error.log、尤其是 binary log（mysql-bin.*），单个文件可达数 GB，且不会自动轮转。
快速扫描这些目录大小：
sudo du -sh /var/log /var/log/journal /var/lib/mysql 2>/dev/null第三步：精准揪出具体的大日志文件
进入可疑目录后，用以下方式聚焦问题文件：
- 在 /var/log 下：ls -lhS /var/log | head -10（按文件大小倒序列出前 10 个）；
- 查 journal 占用详情：journalctl --disk-usage；
- 查 MySQL 日志：find /var/lib/mysql -name "*.log" -o -name "mysql-bin.*" -size +100M -ls 2>/dev/null；
- 通用大文件搜索（慎用，耗时）：find /var -type f -size +500M 2>/dev/null。
特别注意：如果某个日志文件大小不变但磁盘不释放，可能是它已被删除但仍有进程在写（lsof + deleted），运行 lsof +L1 可识别这类“幽灵文件”。
清理前必须确认的两件事
- 该日志是否还在被服务实时写入？例如 nginx 正在往 access.log 写，直接 rm 会导致新日志写不进、服务异常；应先 reload 或用 truncate 清空内容；
- 该日志是否有业务依赖？binary log 关系主从同步和恢复，error log 是故障线索，不能无脑删，要结合用途决定清理方式（如 PURGE MASTER LOGS 而非 rm）。
