先用df -h确认日志所在分区是否真满，重点关注/var/log对应挂载点的use%和avail；若接近100%或avail为0，再用sudo du -sh /var/log/* 2>/dev/null | sort -hr | head -n 10筛选异常目录，接着用sudo find /var/log/xxx -type f -size +100m -exec ls -lh {} \;定位大文件，最后用sudo lsof -np +l1 | grep -i 'log|error|journal'排查已删未释放的“幽灵文件”。
查 df -h 确认是不是日志分区真满了
磁盘“瞬间满载”往往不是日志本身增长快，而是某个日志文件突然暴增（比如 MySQL 错误日志写崩、Nginx access_log 未轮转、auditd 日志失控）。第一步必须确认问题是否出在日志所在分区：df -h 输出里重点看 /var/log 对应的挂载点——它可能和根分区 / 合并在一块，也可能单独挂载为 /var 或 /var/log。如果 Use% 达到 100% 或只剩几 MB Avail，才值得往下深挖日志；否则可能是其他目录（如 /tmp、/var/lib/docker）或 inode 耗尽导致的假性满载。
用 du -sh /var/log/* 快速筛出异常日志目录
进入 /var/log 后别直接 du -sh * 全扫——有些子目录（如 journald 或 containers）可能有权限限制或大量小文件拖慢速度。推荐这条命令：sudo du -sh /var/log/* 2>/dev/null | sort -hr | head -n 10。它会：
- 忽略无权限读取的目录（
2>/dev/null） - 按大小倒序排列（
sort -hr），一眼看到最大的几个 - 只显示前 10 行，避免刷屏
常见“暴增嫌疑”目录：/var/log/journal（systemd-journald 未配清理策略）、/var/log/mysql（错误日志未轮转）、/var/log/nginx（access_log 单文件超 10GB）、/var/log/audit（审计日志被高频触发）。
对可疑目录用 find -size +100M 定位单个大文件
找到异常目录后（比如 /var/log/mysql 占了 35G），下一步是揪出具体哪个文件在作祟。不要用 ls -lSh——它只按字母排序，大文件可能藏在中间。用这个命令：sudo find /var/log/mysql -type f -size +100M -exec ls -lh {} \;。注意几点：
-
+100M是阈值，可按需调低（如+50M）或调高（+1G） -
-type f排除目录和 socket 文件，只查普通文件 - 如果输出为空但目录仍很大，说明可能是被删除但未释放的“幽灵文件”，得用
sudo lsof +L1查看
典型结果示例：-rw-r----- 1 mysql mysql 24G Sep 7 22:15 /var/log/mysql/error.log——这基本就是罪魁祸首。
验证是否被进程占用：lsof +L1 和 lsof -nP +L1 | grep log
有时候你 rm -f 了一个 20G 的日志，df 却不释放空间——因为还有进程在往它的文件描述符里写。这时 lsof +L1 会列出所有已删除但链接数为 0 的文件（即“幽灵文件”）。但输出可能很长，建议加过滤：sudo lsof -nP +L1 | grep -i 'log\|error\|journal'。关键看三列：
- 第一列（COMMAND）：哪个进程在占着它（如
mysqld、rsyslogd） - 最后一列（NAME）：原路径（如
/var/log/mysql/error.log (deleted)） - 如果看到这类输出，重启对应服务（如
sudo systemctl restart mysqld）才能真正释放空间
这个步骤容易被跳过，但恰恰是“删了没用”的根本原因——很多运维在 du 找到大文件后直接 truncate -s 0，却忘了检查是否被进程锁定。
