关键看iostat -x 1的wkB/s、%util、await和avgqu-sz指标，结合iotop -oP确认nginx写入占比，并检查access_log是否启用buffer/flush及logrotate是否触发fsync。
直接看磁盘 I/O 是否被 Nginx 日志写入拖慢，关键不是只盯日志文件大小，而是观察实时写入行为对磁盘的占用程度。iostat 是最轻量、最可靠的切入点。
重点关注 iostat -x 1 的核心指标
运行 iostat -x 1 后，每秒刷新一次输出，需紧盯以下几列：
- wkB/s：每秒写入 KB 数。若该值持续高于磁盘理论吞吐（如普通 SATA SSD 约 400–500 MB/s，即 400000–500000 kB/s），需警惕；但更常见的是单块机械盘长期维持在 20000+ kB/s 就已偏高。
- %util：磁盘利用率。超过 85% 持续波动，说明磁盘基本处于满负荷状态；接近或达到 100%，大概率是瓶颈源头——Nginx access.log 和 error.log 的同步刷盘、日志轮转（logrotate）或未开启 buffer 都可能推高此项。
- await：I/O 平均响应时间（毫秒）。常规应低于 10 ms；若稳定在 30 ms 以上，尤其伴随 %util 高企，说明请求在队列中等待过久，写入存在明显延迟。
- avgqu-sz：平均队列长度。大于 1 表示常有积压；持续 >2–3 通常意味着 I/O 路径已饱和。
确认是不是 Nginx 在“猛写”
iostat 只告诉你“磁盘忙”，不告诉你“谁干的”。要锁定 Nginx 进程本身是否为写入主力，需配合：
- iotop -oP：仅显示正在执行 I/O 的进程（-o）且只显示实际进程（-P）。观察 nginx worker 进程的 WRITE 列，若其 kB_read/s 或 kB_wrtn/s 显著高于其他进程，尤其是写入速率与 wkB/s 趋势一致，基本可确认日志写入是主因。
- 检查日志配置：查看 nginx.conf 中 log_format 和 access_log 指令。若使用 access_log /path/to/access.log main flush=1s，说明启用了 1 秒缓冲，能大幅降低写频次；若缺失 flush 参数或设为 flush=0，则每次请求都 sync 写盘，极易引发 I/O 尖峰。
- 留意 logrotate 行为：用 strace -p $(pgrep nginx | head -1) -e trace=write,fsync 短暂跟踪主进程，若在日志轮转时刻（如每天 00:00）大量出现 fsync 调用，说明 rotate 脚本触发了强制刷盘，这是典型瞬时瓶颈点。
快速缓解日志写入压力的实操建议
不改架构也能见效快：
- 为 access_log 添加 buffer=64k flush=5s，兼顾实时性与吞吐；error_log 可设为 buffer=4k，它本身写入频次低，缓冲收益明显。
- 将日志目录挂载到独立 SSD 分区（非系统盘），避免和 rootfs 或数据库共用同一物理磁盘。
- 禁用 access_log 对静态资源（如 .js/.css/.png）的记录：用 location 匹配后加 access_log off;，减少 30%–60% 的日志体积和写入量。
- 若用 syslog 方式转发日志（access_log syslog:server=127.0.0.1:514;），则完全剥离本地磁盘写入，但需确保 rsyslog/rsyslogd 配置合理、队列不堆积。
排查 IO 瓶颈本质是做减法：先确认 Nginx 日志是否真在压垮磁盘，再针对性收口。iostat 提供的是客观证据，不是猜测依据。
