Nginx 中 client_body_buffer_size 配置调优与内存分配

调优client_body_buffer_size的核心是让绝大多数请求体全程驻留内存、避免磁盘写入；需依据P95/P99请求体大小上浮25%预留余量，同步配置client_max_body_size≥该值、client_body_temp_path权限与I/O健康、client_body_timeout为10–60秒，并通过debug日志中“buffered in memory”确认生效。

调优 client_body_buffer_size 的核心目标，是让绝大多数请求体全程驻留在内存中处理，避免写入临时磁盘文件——这不靠堆大数值，而靠匹配真实上传分布、避开 Nginx 内部机制陷阱，并控制单请求内存开销。

按真实请求体大小设值，别信“最大”或“平均”

该参数按每个请求独立分配内存。设为 4M，意味着每笔 POST 请求最多占用 4MB 内存，但是否真用满，取决于实际请求体长度：

1. 统计 access log 或前端埋点中的 Content-Length，重点取 P95（95% 请求 ≤ X）和 P99 值，而非平均值
2. 纯 JSON API（含 JWT）：64KB–128KB 覆盖多数场景
3. 头像/Base64 表单（通常 ≤500KB）：建议 128KB–512KB
4. 文档/压缩包上传（≤20MB）：2MB–4MB 可行，但需同步评估并发压力
5. 高并发轻量提交（如 IoT 心跳）：反而可调小到 4KB，省内存换连接数

避开 Nginx 的“25% 自动余量”临界陷阱

Nginx 在已知请求体长度时，会尝试按配置值 × 1.25 分配缓冲区。哪怕只超 1 字节，就触发落盘：

1. 设 256KB，实测最大请求体为 255KB → 因 255 × 1.25 ≈ 319KB > 256KB，仍可能写临时文件
2. P95 是 320KB → 建议设 512KB 或直接 1MB，跳过临界区
3. P99 是 4.8MB → 设 6MB（4.8 × 1.25），比设 5MB 更稳妥
4. 前端限制上传 ≤512KB → Nginx 中设 client_body_buffer_size 512k 是合理起点

必须同步配齐三项配套设置

单独改 client_body_buffer_size 几乎无效，以下三者需同作用域（http、server 或 location）声明且逻辑自洽：

1. client_max_body_size ≥ 缓冲区值，且作用域一致（推荐放在 location 块内）。否则合法大请求还没进缓冲区就被 413 拦截
2. client_body_temp_path 必须指向可写、有空间、低延迟路径（如 /dev/shm/nginx-body），即使缓冲设得再大，超限仍要落盘，这个目录必须可靠
3. client_body_timeout 建议设 10–60 秒（常用 30s），防慢速上传长期霸占缓冲区，拖垮整个 worker 进程

验证是否真走内存，不靠 reload 靠日志

配置 reload 成功 ≠ 行为生效。必须观测运行态：

1. 开启 debug 日志：error_log /var/log/nginx/debug.log debug;，搜索 "http client request body buffered in memory"（走内存）或 "temp file"（落盘）
2. 检查 client_body_temp_path 目录下临时文件生成频率与体积，明显减少即说明缓冲区起效
3. 用 top 或 htop 观察 nginx worker 进程 RSS 内存波动，避免持续攀升
4. 用 strace -p $(pgrep nginx) -e trace=openat 看上传时是否调用临时路径，无调用才真正避开了磁盘 I/O