nginx高并发下日志写入成磁盘i/o瓶颈，表现为延迟升高、错误率上升、iowait偏高但error.log空白；应通过iostat查await>50ms和%util≈100%定位，iotop确认nginx worker高频小写，lsof核实文件路径，strace验证buffer/flush配置是否生效，并排除debug级error_log、临时文件直写及logrotate异常等干扰。
高并发压测下，Nginx 日志写入成为磁盘 I/O 瓶颈很常见，但表现往往隐蔽：响应延迟升高、错误率上升、iowait 持续偏高，而 error.log 却可能一片空白。排查关键不是“看日志”，而是绕过日志本身，直接观察系统行为和 Nginx 写操作逻辑。
盯住磁盘 I/O 实时指标
用 iostat -x 1 持续观察日志所在磁盘（如 /dev/sdb）的两个核心指标：
- await：平均每次 I/O 请求等待毫秒数。压测中若持续 >50ms，说明磁盘响应已吃紧；
- %util：设备忙时百分比。长期接近 100%，代表磁盘几乎无空闲时间处理新请求。
如果这两项在压测中飙升，且与请求量正相关，就基本锁定是磁盘写入拖慢了整体响应。
定位真实写盘进程和目标文件
运行 iotop -o -P，只显示实际执行 I/O 的进程。重点关注 nginx worker 进程的 WRITE 行为：
- 若看到大量小块写（如 4KB、8KB）且频率极高，大概率是未启用缓冲的 access_log 或 debug 级 error_log 在同步刷盘；
- 接着用 lsof -p [PID] 查该 worker 打开的文件，确认 WRITE 是否指向 access.log 或 error.log —— 注意排除 /var/lib/nginx/body/、/var/lib/nginx/proxy_temp/ 下的临时文件，它们属于 client_body_in_file_only 或 proxy_buffering 关闭导致的直写，不是日志问题。
跟踪系统调用验证缓冲是否生效
对任意一个 worker 进程执行：
strace -p $(pgrep -f "nginx: worker") -e trace=write,fsync,fdatasync -s 128 2>&1 | grep -E "(log|access|error)"
观察输出规律：
- 开启 buffer=64k flush=5s 后，write() 调用应明显变少（日志暂存内存），而 fsync() 或 fdatasync() 应大致每 5 秒出现一次；
- 若 write() 频繁出现且无规律 fsync，说明缓冲未生效——检查配置是否写在正确的 http/server/location 块中，或是否被其他 access_log 指令覆盖。
排除干扰项：error_log 和非日志写入源
很多“日志瓶颈”其实是假象：
- error_log 不支持 buffer/flush。若设为 debug 级别，它会持续同步小写，iostat 中看到的 I/O 很可能来自它，而非 access_log；
- 启用 client_body_in_file_only on 或 proxy_buffering off 时，大请求体或响应体会直写磁盘临时文件，这类 fd 在 lsof 中路径明确（如 /var/lib/nginx/body/xxx），别误判为日志句柄；
- 检查 logrotate 是否正常运行：用 ls -lt /var/log/nginx/*.log* 看轮转是否卡住，残留大量 .log.1、.log.2.gz 会快速耗尽 Inode（df -i 查）。
