排查Nginx代理大响应体引发磁盘I/O过高，关键是确认“为何必须落盘”及“是否合理”，需按四步走：定位I/O源头（iotop/lsof/iostat）、分析日志间接线索（error_log/upstream_response_time）、核查proxy_buffers等参数是否匹配P95响应体、最后调优缓冲与落盘策略（如增大buffer、调大temp_file_write_size、移至内存盘）。
排查 Nginx 代理大响应体引发的磁盘 I/O 过高，关键不是看“有没有写磁盘”，而是确认“为什么必须落盘”“写得是否合理”。核心路径是：从 I/O 行为定位源头 → 结合日志与配置判断缓冲是否不足 → 验证是否属于预期暂存 → 最后针对性调优。
观察磁盘写入行为，锁定临时文件目录
先确认高 I/O 是否真由 Nginx 代理响应落盘引起：
- 用 iotop -o -P 查看实时写盘进程，聚焦 nginx worker 的 WRITE 行为
- 执行 lsof -p $(pgrep nginx) | grep -E "(proxy|fastcgi|client)_temp"，检查是否大量打开
.tmp文件（如/var/lib/nginx/proxy_temp/xxxxxx.000001） - 运行 iostat -x 1，关注日志盘或
proxy_temp_path所在分区的%util和await；若这两项在请求高峰同步飙升，且写操作集中在临时目录，基本可断定是响应体缓存溢出所致
分析日志线索，识别缓冲瓶颈信号
Nginx 不会直接报“缓冲区太小”，但会在日志中留下关键间接证据：
- 在 error.log 中搜索：
upstream sent too large response、an upstream response is buffered to a temporary file、upstream sent too big header（后者提示proxy_buffer_size不足） - 检查 access.log：启用含
$upstream_response_time和$body_bytes_sent的自定义格式，比对发现大量响应体在 512KB–4MB 区间，但upstream_response_time明显长于后端真实耗时——说明 Nginx 正边收边写磁盘 - 若日志中频繁出现状态码 499（客户端主动断连），且伴随高
request_time但低upstream_response_time，很可能是客户端接收慢导致 Nginx 缓冲区填满后被迫落盘并等待超时
核查代理缓冲关键参数是否匹配业务响应规模
默认配置（proxy_buffers 8 4k = 32KB）对任何中等以上响应都极易触发落盘。需按 P95 响应体大小调整：
-
proxy_buffers：总量应略大于典型响应体（留 20% 余量）。例如报表接口 P95 为 1.2MB，可设
proxy_buffers 16 128k（共 2MB） -
proxy_busy_buffers_size：必须设为总 buffer 的 1/4～1/2，且 ≥ 单块大小。上例中建议设
512k或1m；若设太小（如仍用默认8k），Nginx 会过早刷盘甚至压制后端连接 -
proxy_buffer_size：仅管响应头。若 error.log 提示 header 过大，需单独调大（如
32k），但不能超过单块proxy_buffers大小 -
proxy_temp_file_write_size：默认
8k会导致高频小写。调大至256k或512k可显著降低 write() 系统调用频次
控制落盘影响，避免误报与资源失控
完全禁用落盘不现实，重点是让其可控、可预期、低干扰：
- 将
proxy_temp_path指向内存盘（如/dev/shm/nginx_temp），跳过物理磁盘；注意设置子目录层级（如1 2）以提升并发性能 - 限制单文件上限：
proxy_max_temp_file_size 500m（而非默认 1G），既防突发大响应占满磁盘，也减少监控误判 - 监控层面排除临时目录 I/O：在 iostat/iotop 告警规则中过滤
proxy_temp、fastcgi_temp路径，或为其打标（如io_source=nginx_temp）单独建模 - 若业务明确无需缓冲（如视频流、大文件下载），直接关掉：
proxy_buffering off，此时所有参数失效，Nginx 流式转发，彻底规避落盘
