%util高但await低，通常是顺序大块写（如日志追加）所致，并非随机IO瓶颈；需结合w/s、wkB/s及设备类型判断，再通过iotop、lsof和journalctl等工具定位具体日志文件与写入节奏。
iostat 显示 %util 高但 await 不高，是不是日志写入导致的？
不是必然。%util 高 + await 低，更可能是顺序大块写（如日志追加），而非随机 IO 瓶颈；但恰恰是这种“安静的高负载”最容易被忽略——它不卡进程，却持续拖慢磁盘响应。关键看 r/s 和 w/s：如果 w/s 很高（比如 >500）、wkB/s 也高（比如 >20MB/s），且设备是 HDD（ROTA=1），那基本就是日志类顺序写在饱和磁盘。
如何确认是哪个日志文件在狂写？
不能只靠 iotop 看进程名，得穿透到文件层：
- 先用
sudo iotop -o -P -d1锁定高DISK WRITE或高IO>的进程（比如rsyslogd、journalctl、nginx、业务 Java 进程） - 再对 PID 执行
lsof -p <pid> | grep -E '\.log$|/var/log|/data/log'</pid>，重点筛出打开的 log 文件 - 用
ls -lh /path/to/logfile看大小和修改时间；若文件每秒增长几 MB 且tail -f实时有输出，基本坐实 - 注意：systemd-journald 写的是二进制
/run/log/journal/下的文件，lsof可能不显路径，改用journalctl --disk-usage查用量
journalctl 或 rsyslog 日志刷盘太猛怎么办？
不是关日志，而是控节奏：
- systemd-journald：编辑
/etc/systemd/journald.conf，调低RateLimitIntervalSec=30s和RateLimitBurst=10000（默认 10k 条/30s），避免突发日志洪峰打满 IO - rsyslog：在
/etc/rsyslog.conf或/etc/rsyslog.d/*.conf中，给高频日志加$ActionFileEnableSync off（禁用每次写都 fsync），或用$ActionQueueSize 100000启用队列缓冲 - 业务应用：检查是否开启 debug 级日志；Java 应用常见
logback.xml中<rollingpolicy></rollingpolicy>未配timeBasedFileNamingAndTriggeringPolicy，导致单个日志文件无限增长，触发大量小块 write+fsync
为什么 df -h 看磁盘没满，IO 却卡死？
因为日志写入瓶颈跟空间剩余无关，跟以下三点强相关：
-
ext4文件系统在日志模式（data=ordered默认）下，每次写都要先刷 journal 区域——这个区域通常很小（几 MB），频繁小写会迅速打满其带宽 - SSD 的
TRIM或 GC 延迟可能被日志连续写触发，表现为await波动大但%util不爆表 - 容器环境里，宿主机看到的
DISK WRITE是 cgroup 统计值，但实际落盘可能被 overlayFS 多层拷贝放大，iotop显示的速率远低于真实物理写入量
真正要盯的不是磁盘用了多少，而是 journalctl --disk-usage、dmesg | grep -i "journal"、以及 /proc/sys/fs/jbd2/*/stats 里的 nr_sync 和 nr_wait——这些才是日志子系统真实压力的刻度。
