如何通过分析 request_time 监控静态资源磁盘 IO 的响应毛刺-Nginx-PHP中文网

request_time 是 nginx 记录的客户端请求总耗时（秒，毫秒精度），包含磁盘io、缓存、网络等全部环节；当静态资源走本地文件系统且未命中page cache时，其异常升高常反映磁盘io毛刺，但需结合是否真实触发io路径（如非proxy_pass、冷缓存、未启用sendfile等）综合判断，并通过定制日志与系统io指标（iostat/vmstat/pidstat）关联验证，再针对性优化。

如何通过分析 request_time 监控静态资源磁盘 io 的响应毛刺

request_time 是 Nginx 记录的客户端请求从接收首字节到发送完响应的总耗时（单位秒，精度毫秒），它天然包含了静态资源读取磁盘、处理缓存逻辑、网络传输等全部环节。当静态资源走的是本地文件系统（如 alias 或 root 配置）且未命中内存页缓存（page cache）时，磁盘 IO 成为关键瓶颈，此时 request_time 的异常升高往往就是磁盘 IO 毛刺的直接体现。

关键点：区分 request_time 是否真由磁盘 IO 引起

不能一看到 request_time 高就断定是磁盘问题。需结合上下文判断是否满足“IO 路径真实触发”条件：

请求确实命中了本地静态文件（非 proxy_pass 到后端）；
文件未被内核 page cache 缓存（冷缓存或 cache 被频繁淘汰）；
Nginx 未启用 sendfile 优化（或虽启用但文件过大/不支持零拷贝场景）；
排除网络延迟（如用 $upstream_response_time 为 -，且 $status 为 200，基本可排除 upstream 影响）。

构建可定位的静态资源日志格式

仅记录 request_time 不够，必须绑定资源特征与 IO 环境。推荐定义如下 log_format：

log_format static_io '$time_iso8601|$request_id|$request_method|$request_uri|'  
                      '$status|$body_bytes_sent|$request_time|'  
                      '$sent_http_content_length|$sent_http_content_type|'  
                      '$connection_requests|$msec';

重点字段说明：

$request_time：总耗时，毛刺主观察指标；
$body_bytes_sent + $sent_http_content_length：确认是否真实返回了文件内容（排除空响应干扰）；
$sent_http_content_type：过滤出典型静态类型（如 image/jpeg, application/javascript, text/css）；
$connection_requests：同一连接复用次数，辅助判断是否因连接复用掩盖了单次 IO 延迟；
$msec：精确到毫秒的时间戳，用于对齐系统级 IO 监控（如 iostat -x 1）。

聚焦分析：筛选高耗时静态请求样本

在日志中快速定位疑似 IO 毛刺的请求，可用如下思路过滤：

按耗时阈值筛选：$request_time > 0.5（500ms）且 $status == 200；
按文件大小筛选：$body_bytes_sent > 10240（>10KB），避免小文件噪声；
按类型筛选：$sent_http_content_type ~ "^(image/|text/|application/(javascript|css))"；
排除高频重复路径：如 /favicon.ico、/healthz 等非典型静态资源。

例如用 awk 快速提取：

awk -F'|' '$3=="GET" && $5==200 && $7>0.5 && $6>10240 && $8~/^(image\/|text\/|application\/(javascript|css))/' access.log

关联系统层 IO 指标做归因

找到可疑请求后，需验证是否与磁盘负载尖峰同步：

查看同一时间点的 iostat -x 1 输出，重点关注：
- %util 是否持续 >80%；
- await（平均 I/O 请求等待时间）是否突增至毫秒级以上；
- r/s（每秒读请求）是否激增，且 rkB/s 与静态文件总大小量级匹配；
检查 vmstat 1 中 bi（块设备接收字节数/秒）是否同步冲高；
使用 pidstat -d 1 定位是否 nginx worker 进程本身在大量 READ。