iostat不直接监控nginx worker进程，而是统计块设备级i/o；需结合iotop、lsof及nginx配置（如access_log缓冲、sendfile、proxy_cache）联动分析%util、await、w/s等指标，才能准确归因磁盘压力来源。
看设备级 IO 压力，定位瓶颈是否在磁盘
iostat -xdm 1 是最常用命令，重点关注三类指标：
- %util：磁盘忙时百分比。持续 >85% 表示设备饱和，可能是大量小文件读取、日志刷盘或 proxy_cache 落盘导致
- await：I/O 请求平均等待时间（毫秒）。>10ms（HDD）或 >1ms（SSD/NVMe）说明响应延迟高，需检查文件系统缓存命中率或磁盘队列深度
- r/s 和 w/s：每秒读/写请求数。若 w/s 异常高，结合 nginx 配置排查 access_log 是否未启用缓冲、error_log 是否频繁报错、或 proxy_cache_path 是否配置了 disk_inactive 过短导致频繁落盘
关联 Worker 进程行为，缩小归因范围
仅靠 iostat 无法确认是哪个进程引起的 IO，必须配合其他工具交叉验证：
- 运行
iotop -oP -p $(pgrep -f "nginx: worker")，实时查看所有 worker 进程的实时读写速率（KB/s），确认是否存在个别 worker 写日志或刷缓存异常 - 用
lsof -p <worker_pid> | grep -E "(log|cache|html|jpg)"</worker_pid>检查该 worker 打开的关键文件路径，判断其是否正服务大量静态资源或写入特定日志文件 - 对比
cat /proc/sys/vm/vfs_cache_pressure和free -h，确认 page cache 是否充足——若 cache 占用低但 iostat 显示高 r/s，说明静态文件缓存未命中，Worker 不得不频繁触发物理读
结合 Nginx 配置预判 IO 模式
Worker 进程是否产生可观磁盘 IO，高度依赖配置。以下配置项直接影响 iostat 观测结果：
-
sendfile on;：启用后，大部分静态文件传输走零拷贝路径，绕过用户态 read()，iostat 中 r/s 可能不高，但 await 仍可能上升（内核 page cache 缺页时仍需磁盘读） -
access_log /path/log.log buffer=64k flush=5s;：带缓冲和定时刷盘的日志显著降低 w/s；若省略 buffer，每次请求都 write+fsync，iostat 中 w/s 和 %util 会剧烈跳升 -
proxy_cache_path /cache levels=1:2 keys_zone=mycache:10m max_size=1g use_temp_path=off;：use_temp_path=off 可减少一次写入；若磁盘慢且 cache 大量填充，iostat 将显示持续 w/s
典型误判提醒
不要看到 iostat %util 高就断定是 Nginx 的问题。常见干扰源包括：
- 数据库备份脚本在同一磁盘执行 dd 或 mysqldump
- logrotate 每日凌晨触发日志轮转并压缩（尤其未配置 delaycompress）
- 系统级 cron 清理 /tmp 或 journalctl --vacuum-size，与 Nginx 流量高峰重叠
