Nginx高并发平滑重载稳定性测试核心是验证请求不丢、连接不断、延迟不跳，需在wrk压测洪峰中触发reload，同步监控Active connections、错误率及P95/P99延迟，并用tcpdump确认无RST和连接重建。
测试高并发压测中 Nginx 平滑重载（nginx -s reload）的稳定性，核心是验证“请求不丢、连接不断、延迟不跳”。这不是看 reload 命令执行快不快，而是看它在真实流量洪峰里是否真正无感。
构造可信的对抗性压测环境
必须让 reload 发生在压力最重的时刻，而非空闲时：
- 用
wrk -t8 -c2000 -d300s --latency http://ip/test.html持续施压，保持 QPS 在 1.5–3 万区间（按机器能力调整），目标资源为 1KB 静态文件，关闭 access_log、gzip 和 sendfile 干扰 - 压测机与 Nginx 服务器物理分离，走万兆直连；每次 reload 前执行
sync && echo 3 > /proc/sys/vm/drop_caches清缓存，避免内核缓存掩盖问题 - 确保 Nginx 已启用
stub_status，并配置worker_shutdown_timeout 10s，同时 error_log 级别设为 notice 或更高，以便捕获 “reloading”、“gracefully shutting down” 等关键日志
reload 过程中盯紧三类实时指标
不能只等压测结束看汇总结果，要在 reload 瞬间同步观察：
-
连接连续性：通过
/nginx_status查 Active connections 是否突降归零；用ss -s看 total established 连接数是否平稳，Waiting 数是否长时间堆积（说明新 worker 接管延迟） - 请求成功率：wrk 输出中的 Non-2xx or 3xx responses 是否在 reload 后 1–3 秒内出现尖峰；同时检查后端 access_log 或 upstream 错误率（如 502/504）是否同步上升
-
响应延迟稳定性：关注 wrk --latency 输出的 P95/P99 延迟是否瞬间拉高（＞500ms）；若使用 Prometheus + nginx-module-vts，可对比 reload 前后 upstream 的
response_time_seconds分位值
用抓包确认 TCP 层是否真正平滑
日志和状态页只能间接推断，tcpdump 才能一锤定音：
- 在客户端或 Nginx 侧执行：
tcpdump -i any port 80 -w reload.pcap host [client_ip]，在 wrk 运行中触发 reload，抓取前后各 5 秒流量 - 重点过滤 reload 时间点附近的包：确认没有突发的 RST（连接被强制终止）、没有大量重传（retransmission）、没有 SYN 重发（客户端重连）
- 对 keepalive 连接，检查同一 TCP 流在 reload 后是否继续收发 HTTP 数据帧（而非断开重建），这直接证明长连接复用未受影响
排查 reload 失效的典型卡点
一旦发现丢请求或延迟跳变，按链路快速定位：
-
文件描述符耗尽：运行
cat /proc/$(pgrep nginx)/limits | grep "Max open files"，确认worker_rlimit_nofile与系统ulimit -n一致且 ≥65535 -
旧 worker 拖尾过长：reload 后用
ps aux | grep nginx查旧 worker PID 是否超 15 秒仍未退出；再用lsof -p [old_pid] | grep sock看是否还持有大量 socket，常见于 proxy_read_timeout 过长或后端未响应 -
内核连接队列溢出：检查
netstat -s | grep -i "listen overflows"，若数值增长，说明net.core.somaxconn或 Nginx 的listen ... backlog=设置不足
