测试Nginx极限worker_connections内存稳定性，核心是观察高连接长期维持时内存是否线性增长、有无抖动或OOM；需先配平系统/file-max、用户/limits.conf、Nginx/worker_rlimit_nofile三层上限，再用wrk长连接压测，分进程/RSS、连接/lsof、内核/Slab三层监控归因，并按HTTPS/WebSocket/代理场景识别失稳模式。
测试 Nginx 在极限 worker_connections 下的内存稳定性，核心是观察高连接数长期维持时内存是否线性增长、有无异常抖动或 OOM 崩溃，而非只看瞬时峰值。关键在于“稳住连接、持续观测、分层归因”。
一、先配平三层资源上限，避免假瓶颈
内存异常往往源于底层限制未对齐，导致连接挤压、缓冲区堆积或重试激增：
- 系统级：
/proc/sys/fs/file-max≥worker_processes × worker_connections × 1.3（例如 4×65535 → 设为 360000） - 用户级：
/etc/security/limits.conf中运行 Nginx 的用户（如www-data）需设soft/hard nofile 262144 - Nginx 级：
worker_rlimit_nofile必须显式声明，且 ≥worker_connections × worker_processes - 验证是否生效：
cat /proc/$(pgrep nginx)/limits | grep "Max open files"，输出值应与 limits.conf 一致
二、用长连接压测工具模拟真实内存压力
短连接（如 ab）无法触发连接保活带来的内存累积效应；必须用支持 keepalive 的工具，让连接真实驻留：
- 推荐
wrk：启动命令示例：wrk -t8 -c100000 -d10m --timeout 30s -H "Connection: keep-alive" http://127.0.0.1/healthz
其中-c100000模拟 10 万并发连接，-d10m持续 10 分钟，确保连接池稳定进入 steady state - 禁用后端交互干扰：后端返回固定小响应体（如
200 OK {"ok":true}），关闭 proxy_cache、proxy_buffering，避免缓存和缓冲区放大内存占用 - 静态文件兜底：location 中用
try_files /healthz =404;直接由 Nginx 返回，排除 upstream 变量影响
三、分层监控内存变化，定位增长源头
不只看 top RSS，要拆解到进程、连接、内核三层面：
-
进程级：每 30 秒执行
ps -o pid,rss,vsz,comm -p $(pgrep nginx)，绘图观察 RSS 是否随连接数线性上升（理想斜率 ≈ 单连接内存开销） -
连接级：用
lsof -p $(pgrep nginx) | wc -l和ss -s | grep "TCP:"对比，若 lsof 数远大于 ESTAB 数，说明大量连接处于半开或缓冲堆积状态 -
内核级：检查
/proc/meminfo中Slab、SReclaimable是否持续上涨（Nginx epoll、SSL session cache 多分配 slab 内存） - 重点抓异常信号：
dmesg -T | grep -i "killed process.*nginx"或journalctl -u nginx | grep -i "oom\|segfault"
四、识别典型内存失稳模式并对应验证
不同业务模型下内存异常表现不同，需针对性验证：
-
HTTPS 长连接场景：启用
ssl_session_cache shared:SSL:10m后，RSS 显著升高但稳定 → 属正常；若持续缓慢上涨超过 30 分钟，检查ssl_session_timeout是否过长（建议 ≤ 4h） -
WebSocket 场景：用
ss -nt | awk '{print $1}' | sort | uniq -c | sort -nr查看 ESTAB 连接分布，若某 worker 连接数远高于其他，说明reuseport未生效或worker_cpu_affinity不均，引发单 worker 内存局部超限 -
代理转发场景：开启
proxy_buffering off后内存下降明显 → 说明原 buffer 配置（如proxy_buffers 8 64k）在高连接下造成缓冲区倍增，应调小或按需启用
