Stream模块不使用GPU显存，其“内存池调优”实为对连接池、共享内存区（zone）、缓冲行为及worker协同的精细化配置，目标是支撑海量并发TCP连接时避免内存暴涨、连接堆积、状态不同步或频繁分配开销。
Stream 模块本身不使用“显存”（GPU memory），它运行在 CPU 和内核网络栈层面，管理的是内存（RAM）中的连接状态、缓冲区和共享数据结构。所谓“stream 模块的内存池调优”，实际是指对 stream 上下文中的连接池、共享内存区（zone）、缓冲行为及 worker 进程间资源协同 的精细化配置，目标是支撑海量并发 TCP 连接时，避免内存暴涨、连接堆积、状态不同步或频繁分配释放开销。
upstream 连接池：复用后端连接，压降内存与建连开销
这是 stream 层最核心的“内存池”机制——不是预分配 GPU 显存，而是复用已建立的到后端服务（如 MySQL、Redis、自定义 TCP 服务）的空闲连接。
-
keepalive N：在 upstream 块中声明最大保活连接数（例如
keepalive 64;）。每个 worker 进程维护自己的空闲连接池，N 建议设为单台后端节点连接处理能力的 1/2～1/3，避免池过大导致内存冗余，过小则复用率低 -
keepalive_timeout T：控制空闲连接最长保留时间（如
keepalive_timeout 60s;）。超时自动关闭，防止僵死连接长期占内存和端口 -
务必禁用缓冲：
proxy_buffering off;（stream 模块默认关闭，但显式声明更可靠）。开启缓冲会额外分配内存暂存未转发数据，还可能引发粘包或延迟，对数据库等协议尤其危险
zone 共享内存区：支撑多 worker 协同与健康检查状态同步
当 Nginx 启动多个 worker 进程时，连接计数、失败统计、健康检查状态必须跨进程共享，靠的就是 zone 指令分配的共享内存（shmem）。
-
upstream zone：如
upstream db_cluster { zone tcp_mem 64k; ... }。64KB 可支撑约 200–300 个后端节点的状态同步；高可用集群建议 ≥128k -
limit_conn_zone：用于连接限流，如
limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;。10MB 内存约可记录 16 万个独立客户端 IP 的并发连接数，按实际 IP 规模预留，避免哈希冲突或 OOM - 注意：
zone内存由主进程分配，worker 进程只读写其中指定槽位，不复制整块内存，因此开销可控且高效
worker 级内存控制：避免单点过载与虚假 OOM
海量并发下，单个 worker 承载连接过多会导致内存局部打满（如 socket 缓冲区、连接结构体、临时读写 buffer），触发内核 OOM killer 或连接拒绝。
-
限制单 worker 连接上限：通过
worker_connections 65535;（需配合ulimit -n调高）约束每个 worker 处理的 socket 总数，间接控制其内存占用峰值 -
关闭不必要的日志与调试：stream 模块不支持 access_log，但若误配或开启 debug 日志（
error_log /path debug;），会产生大量字符串拼接与内存分配，应仅在排查时启用 -
避免 proxy_timeout 过长：如设为
proxy_timeout 24h;会让空闲连接长期驻留，占用连接结构体内存和 socket 资源。按业务真实会话周期设置（如数据库一般 30min～2h）
系统层协同：让 Nginx 内存策略真正落地
Nginx stream 的内存效率高度依赖 OS 配合。脱离系统调优谈“连接池”只是纸上谈兵。
-
扩大文件描述符限制：每个 TCP 连接 = 1 个 fd。需同时调高
ulimit -n（进程级）、/proc/sys/fs/file-max（系统级），否则连接新建直接失败 -
优化 TCP 内存参数：如
net.ipv4.tcp_rmem和net.ipv4.tcp_wmem设置合理 min/default/max，避免单连接缓冲区过大挤占总内存；启用tcp_moderate_rcvbuf=1让内核动态调节 -
TIME_WAIT 复用控制：
net.ipv4.tcp_tw_reuse = 1允许将 TIME_WAIT 状态套接字重用于新连接（客户端为公网 IP 时安全），缓解端口耗尽，减少新建连接所需内存分配
