在高负载环境下，如何通过调整Nginx的proxy_max_temp_file_size参数来避免磁盘IO剧烈波动？

本文共计996个文字，预计阅读时间需要4分钟。

此配置控制+Nginx+在+proxy_buffering+开启时，单个临时文件的最大大小。当上游响应体超过+proxy_buffer_size+、+proxy_buffers+总和时，且未被完全缓存于内存中，Nginx会将超出部分写入磁盘临时文件。这些文件的每个上限由+proxy_max_temp_file_size+设定。

高负载下如果大量请求的响应体略超内存缓冲区（比如 128KB ~ 1MB），又没设好这个值，就会频繁创建、写入、合并小临时文件，导致大量随机 IO，表现为 iowait 飙升、iotop 显示 nginx: worker process 持续刷盘。

默认值太保守，高并发场景下必须调大

默认是 1024m（1GB），听起来不小，但实际容易误判：它不是“所有临时文件总大小”，而是“每个临时文件”的上限。Nginx 会把一个大响应拆成多个不超过该值的文件（如 2GB 响应可能生成两个 1GB 文件），而频繁切分正是 IO 抖动的源头。

• 若业务响应体普遍在 5–50MB（如报表导出、大图代理），建议设为 50m～100m，避免切分过多
• 若响应体多在 100KB 以内，可直接设为 0（禁用磁盘临时文件），强制走内存缓冲或直接流式转发（需同时关 proxy_buffering）
• 设为 0 时，Nginx 不会写任何临时文件，但要求 proxy_buffering off 或响应能被完整塞进内存缓冲区，否则会报 502 Bad Gateway

和 proxy_buffering、proxy_buffers 的协同关系

单独调 proxy_max_temp_file_size 没用，它只是“缓冲溢出后怎么落盘”的规则。真正决定是否落盘、落多少，取决于内存缓冲策略：

• proxy_buffering on（默认）：启用缓冲，响应先存内存/磁盘，再发给客户端；此时 proxy_max_temp_file_size 生效
• proxy_buffering off：禁用缓冲，响应边收边转，不落盘也不缓存，proxy_max_temp_file_size 完全无效
• proxy_buffers 8 16k 表示最多用 8 个 16KB 缓冲区（共 128KB），加上 proxy_buffer_size（通常 4k～8k）用于响应头；总内存缓冲 ≈ 132KB～136KB
• 若响应 > 总内存缓冲，且 proxy_buffering on，才走到 proxy_max_temp_file_size 控制的落盘逻辑

实测建议与容易踩的坑

线上调优不能只看文档值，得结合 nginx -t + ab 或 wrk 压测观察 iostat -x 1 和 nginx error log 中的 upstream sent too big header 或 client intended to send too large body 类错误。

• 不要盲目设成 2g：单文件过大虽减少切分，但可能拖慢单个大响应的释放速度，影响 worker 进程调度
• 检查 client_body_temp_path 和 proxy_temp_path 所在磁盘是否 SSD，是否与其他高 IO 服务共盘——即使参数调对，硬件瓶颈也白搭
• 改完必须 nginx -s reload，且注意：已有连接不会立即应用新配置，要等旧连接自然结束或主动断连
• 如果用了 proxy_cache，proxy_max_temp_file_size 对缓存写入过程也有影响，此时还需同步检查 proxy_cache_path 的 levels 和 max_size

最常被忽略的是：这个参数只在 proxy_buffering on 且响应溢出内存时起作用。很多团队压测发现 IO 高，第一反应调它，结果发现其实是 proxy_buffering off 下走流式转发，根本没走这套逻辑——先确认当前 buffering 状态，比调参重要得多。