keepalive_timeout 不直接操作内存池，但通过控制空闲连接存续时间间接影响内存占用；设为15–30秒可减少socket、ssl上下文及缓冲区等per-connection内存累积，避免rss线性增长与fd耗尽。
keepalive_timeout 本身不直接操作内存池，但它通过控制空闲连接的存续时间，间接决定每个 worker 进程中活跃连接数及关联内存占用量——连接越多、越久，内存池中用于维护 socket、SSL 上下文、读写缓冲区等结构的开销就越大。
空闲连接持续驻留，内存持续累积
Nginx 每个 TCP 连接在空闲状态下仍需保留在内存中：包括 socket 控制块、接收/发送缓冲区（默认各 8KB–64KB）、TLS 握手后的会话上下文（HTTPS 下更重），以及连接状态跟踪结构。这些不是“共享内存池”，而是 per-connection 的独立分配。keepalive_timeout 设得过长（如 300 秒），意味着大量连接在无请求时仍长期驻留，内存 RSS 会随并发连接数线性增长。
- 实测显示：当 keepalive_timeout 从 15 秒调至 300 秒，在 5000 并发连接场景下，worker 进程内存占用平均上升 120–180MB
- 尤其在 HTTPS 服务中，每个 SSL 连接额外携带 session ticket、密钥材料等，单连接内存开销可达普通 HTTP 的 3–5 倍
- 内存增长非瞬时，但会持续积累，若未配合适当的 keepalive_requests 或连接回收机制，可能触发 OOM killer
文件描述符耗尽，间接加剧内存压力
每个连接占用一个文件描述符（fd）。worker_connections 和 ulimit -n 共同限制了可用 fd 总数。keepalive_timeout 过长 → 空闲连接堆积 → fd 快速占满 → 新连接被拒绝（报错 “Too many open files”）→ Nginx 可能启动更多临时进程或重试逻辑，进一步抬高内存与 CPU 开销。
- 常见现象：netstat -an | grep ESTABLISHED | wc -l 显著高于实际活跃请求数，且 ss -s 中 “total: 12000” 但 “tcp: 8500” 中多数处于 FIN-WAIT 或 CLOSE-WAIT
- fd 耗尽后，Nginx 无法 accept 新连接，部分请求被内核丢弃或排队，造成响应延迟毛刺，监控中表现为 request_time 突增、502 比例上升
Waiting 状态过高，暴露无效内存驻留
Nginx stub_status 输出中的 Waiting 状态，即处于 keepalive 空闲等待、尚未关闭的连接。该值持续偏高（例如 > 总 Active connections 的 60%），说明大量连接在“空转”，既未复用也未释放，属于典型的内存低效驻留。
- Waiting 高 ≠ 复用率高，反而是复用失败或客户端行为不匹配的信号（如 App 请求间隔 > timeout，但 Nginx 却设了更长 timeout）
- 配合 $connection_requests 日志字段分析：若单连接平均请求数
协同配置才能真正控住内存水位
单独调小 keepalive_timeout 不足以稳定内存，必须和以下两项联动：
- keepalive_requests：建议设为 50–1000（非默认 100 或极端值 100000），防止单连接因复用频繁而长期不释放，避免“长连接变内存黑洞”
- upstream keepalive：后端连接池大小（如 keepalive 32）影响 Nginx 向后端建连频率；若 client 端 timeout 过长而后端 timeout 更短，Nginx 会不断重建上游连接，引发额外内存与 CPU 开销
