文件系统日志写入过重是linux中引发i/o阻塞的常见原因，需通过%wa、iostat、iotop、pidstat、lsof和strace四步定位异常日志进程、路径及同步行为。
文件系统日志写入过重是 Linux 中引发 I/O 阻塞的常见原因，尤其在应用频繁打日志、未做轮转或日志级别设为 DEBUG/INFO 时极易触发。排查关键不是“找哪个文件在写”，而是“确认日志行为是否异常 + 定位到具体进程和路径 + 判断是否由日志机制本身导致”。下面分四步说清楚。
看系统指标：确认是不是日志类 I/O 问题
先排除 CPU、内存等干扰，聚焦 I/O 特征：
-
%wa > 30%（
top中）且 CPU idle 很高 → 进程大量等待磁盘写入 -
iostat -x 1 显示：
wkB/s持续高位（如 >20MB/s）、await>50ms、avgqu-sz>10 → 写请求严重排队 -
load average 显著高于 CPU 核数，但
us+sy总和很低 → 典型 D 状态进程堆积，多由同步日志刷盘引起
盯住写进程：用 iotop 和 pidstat 锁定源头
日志写入通常是持续、稳定、中低吞吐但高频率的小块写，容易被忽略：
- 运行
iotop -o -P，重点关注 DISK WRITE 列持续 >1MB/s 且 IO% 占比高的进程（如java、python、nginx） - 补查
pidstat -d 1，观察 write/s 和 wkB/s 最高的 PID；若某进程 write/s 达数千次/秒，基本可断定是日志狂写 - 注意：有些日志框架（如 Log4j 的
AsyncAppender）会隐藏在后台线程，iotop可能只显示父进程名，需结合ps -T -p $PID查线程
挖日志路径：lsof + strace 验证写入目标
找到进程后，确认它到底在往哪写、怎么写：
-
lsof -p $PID | grep -E "(log|tmp|var)"→ 快速筛出打开的日志文件（如/var/log/app.log、/tmp/debug.out） - 重点看文件描述符状态列：w 表示写打开，u 表示读写，W 表示追加写（常见于日志）
- 用
strace -p $PID -e trace=write,openat,fsync -s 128 2>&1 | grep -E "(write|openat|fsync)"观察是否高频调用fsync()或小块write()（如每次写 128 字节）→ 这是同步日志的典型特征
验证与收口：检查日志配置和文件系统行为
避免误判，需交叉验证是否真由日志引起：
- 查该进程的日志配置文件（如
logback.xml、logging.conf），确认 level 是否为INFO或更低，appender 是否启用了immediateFlush=true或sync=true - 用
df -h /var/log和df -i /var/log排除磁盘满或 inode 耗尽（这两者也会导致 write 阻塞） - 临时测试：停掉该进程日志输出（如改
level=ERROR或重定向到/dev/null），观察iostat的wkB/s和await是否快速回落
