proxy_busy_buffers_size 控制 Nginx 已发给客户端但未确认接收的响应数据缓冲上限，需设为 proxy_buffers 总量的 1/4 至 1/2 且不低于单块大小，设错会引发上游读取阻塞或并发下降。
测试 Nginx 代理缓冲区在极端高并发下的内存稳定性，核心是验证 proxy_buffering、proxy_buffers、proxy_busy_buffers_size 等配置在真实高压场景中是否引发内存持续增长、OOM 或响应截断。它不是测“能不能缓存”，而是测“缓存机制会不会在连接密集、响应体不均、突发大包时失控”。
明确要验证的三个关键行为
缓冲区稳定性问题往往藏在长尾请求和响应不一致中，需聚焦以下具体表现：
-
大响应体堆积：当后端返回 2MB JSON 或图片，而
proxy_buffers总大小仅设为 4×8k（32KB）时，Nginx 是否被迫将剩余数据暂存在 worker 进程堆内存中，导致 RSS 持续上涨 -
忙缓冲区竞争失效：
proxy_busy_buffers_size若小于单个大响应体，Nginx 可能无法释放已发送完的 buffer，造成缓冲区“卡死”，新连接复用时反复分配新内存 -
关闭 buffering 后的副作用：设
proxy_buffering off虽规避缓冲区，但会强制 Nginx 边收边转发，若后端慢、客户端快，就可能触发proxy_buffer_size不足或写超时，反而暴露 socket 层内存泄漏
搭建可归因的压测环境
避免系统干扰，确保观测到的是缓冲区本身的行为：
- 后端响应可控：用 mock 服务统一返回固定大小响应体（如 16KB / 512KB / 2MB），并控制响应延迟（如 50ms / 800ms），禁用 gzip 和 chunked 编码
-
隔离缓冲区变量：每次只调一个参数——例如固定
proxy_buffering on，仅对比proxy_buffers 8 64kvsproxy_buffers 16 128k，其他 buffer 相关指令保持默认 -
启用精准监控项：除常规
rss外，必须采集：
–/proc/<pid>/smaps中[anon]区域的Rss增量
–nginx_stub_status的Active connections+Writing比例（>15% 提示 buffer 写压高）
–ss -i查看每个连接的rcv_ssthresh和unacked，确认是否出现 TCP 接收窗口挤压
分阶段执行与判据
用 wrk 驱动，分三阶段观察内存演化规律：
-
稳态建连阶段（5 分钟）：
wrk -c 5000 -t16 -d300s --timeout 10s http://lb/，观察 RSS 是否线性爬升；若每分钟增 >100MB，说明 buffer 分配未复用 -
突刺注入阶段（1 分钟）：加入 10% 大响应请求（如
GET /api/big?size=2097152），监控Writing连接数是否骤增且不回落，同时检查dmesg是否出现page allocation failure -
退压观察阶段（3 分钟）：停压后持续采样 RSS，若 60 秒内下降 proxy_busy_buffers_size 过小或
proxy_max_temp_file_size 0强制内存驻留）
典型失稳信号与对应配置修正
发现以下现象，基本可定位为缓冲区配置不当：
-
RSS 持续上涨 + Writing 连接数居高不下 → 增大
proxy_busy_buffers_size至 ≥ 最大预期响应体的 1.5 倍，并确认proxy_buffering on未被 location 级覆盖 -
大量 ESTABLISHED 连接 Send-Q > 64KB → 表明后端响应太慢，buffer 已满但无法向客户端推送，应调大
proxy_send_timeout并检查后端 SLA，而非盲目扩 buffer -
OOM Killer 杀 worker，且
pmap -x显示多个[anon]区域 >512MB → 立即设proxy_max_temp_file_size 1024m，允许溢出到磁盘，避免全内存驻留
