proxy_temp_file_write_size应匹配SSD物理特性与业务响应模式：NVMe设256k–512k，SATA SSD设128k–256k，/dev/shm内存盘可设512k或1m；须确保proxy_buffering on、proxy_buffers总量大于write_size、proxy_max_temp_file_size足够支撑单次写入。
要真正榨取 SSD 的写入红利，proxy_temp_file_write_size 不是调得越大越好，而是要匹配 SSD 物理特性、Nginx 缓冲链路和业务响应模式——核心是减少系统调用频次、对齐写入粒度、规避小块随机写。
按 SSD 类型设值：NVMe 与 SATA 不同策略
SSD 的内部页大小通常为 4KB–16KB，但实际高效写入依赖连续大块（尤其是带 DRAM 缓存的企业级 NVMe）：
- NVMe（如 Intel P5800X、长江存储致态TiPlus7100）：推荐 256k–512k。实测在 CDN 回源或大文件代理场景下，512k 比默认 8k 降低 write() 调用频次达 98%，iowait 下降 40%+，且不触发 Nginx 内部缓冲截断；
- SATA SSD 或高负载云盘（如 AWS io2 Block Express、阿里云 ESSD PL3）：建议 128k–256k。过大会导致单次 write 阻塞时间延长，在并发密集时反向拖慢响应；
- 若 proxy_temp_path 已挂载到 /dev/shm（tmpfs）：可设为 512k 或 1m。内存无 seek 成本，大块写更省 CPU，且避免频繁 memcpy。
必须同步满足的三个前提条件
这个参数只在完整缓冲链路就绪时才起效，缺一不可：
- proxy_buffering 必须为 on：设为 off 时整个代理缓冲绕过，该参数完全失效；
-
proxy_buffers 总容量要大于 write_size：例如设了
proxy_buffers 16 256k（共 4MB），再配proxy_temp_file_write_size 512k才有意义；若总 buffer 仅 1MB，数据很快溢出，write_size 再大也白搭； - proxy_max_temp_file_size 要足够支撑单次大写入：若设为 1m，却配了 512k write_size，一个 1.2MB 响应会因“单次写超限”被拒绝或拆成三段，反而增加 I/O 次数。
避开隐性陷阱：别让优化变成负优化
常见踩坑点直接抵消 SSD 优势：
- 不单独挂载 SSD 分区：若 proxy_temp_path 仍指向 /var/tmp（和 rsyslog 共盘），再大的 write_size 也会被日志刷盘抢走 IOPS；
-
忽略文件系统挂载参数：ext4 未加
noatime,commit=60,data=writeback，或 XFS 未启nobarrier,logbufs=8，会导致元数据写放大，吞掉一半 SSD 吞吐； - 混用 client_body_temp_path 和 proxy_temp_path：上传和响应落盘路径若共用同一目录，小请求体（如埋点 POST）会高频创建删除临时文件，严重磨损 SSD P/E 周期。
验证是否真在发挥 SSD 红利
上线后不看配置，看真实行为：
- 运行
iotop -o -p $(pgrep nginx)，观察 WRITE 列是否呈现稳定、低频、大块（如每次 256–512KB）输出； - 检查 error log 是否仍有
"an upstream response is buffered to a temporary file"，若频率明显下降且单个临时文件 size 接近你设的 write_size，说明生效； - 用
cat /proc/diskstats | grep nvme0n1对比前后，重点关注avgrq-sz（平均请求大小）是否从 8–16KB 升至 200KB+，这是最直接的红利证据。
