必须分层压测、监控关键指标并迭代收敛，而非盲目调参；需校准系统层（ulimit、file-max、ss状态）、Nginx层（worker数、服务可达性）和网络层（listen overflows）三重基线，再用wrk阶梯压测，紧盯CPU使用率、ESTAB连接数、TIME-WAIT占比及stub_status中Waiting值四大核心指标。
测试系统内核调优与 Nginx 并发参数的最佳组合，不能靠猜，也不能只看单点配置是否“看起来很猛”。核心思路是：**分层压测 + 关键指标监控 + 迭代收敛**。重点不是跑出最高数字，而是找到稳定、低延迟、资源可控的拐点。
明确压测前必须校准的三层基线
没 baseline 就谈不上“最佳匹配”：
-
系统层：确认
ulimit -n（用户级文件描述符）、cat /proc/sys/fs/file-max（全局最大句柄数）、ss -s中的total:和tcp:状态分布。若file-nr接近上限或大量TIME-WAIT堆积，说明内核参数还没到位； -
Nginx 层：检查
nginx -t通过后，用ps aux | grep nginx验证实际启动的 worker 进程数是否等于worker_processes auto识别的物理核心数；运行curl -I http://127.0.0.1确保基础服务可达； -
网络层：用
netstat -s | grep -i "listen\|overflow"查看是否有listen overflows（说明net.core.somaxconn或backlog不足），这是高并发下请求被静默丢弃的典型信号。
用 wrk 或 go-wrk 做阶梯式连接压力测试
推荐 wrk（轻量、支持 HTTP/2、结果清晰）：
- 先固定并发连接数（如 5k），逐步提升每秒请求数（
-R），观察 99% 延迟是否突增、错误率是否跳升； - 再固定 RPS（如 20k），阶梯增加连接数（
-c 1k → 5k → 10k → 20k），记录 Nginx error log 中是否出现"accept() failed (24: Too many open files)"或"connect() failed (24: Too many open files)"； - 关键命令示例：
wrk -c 10000 -t 16 -d 60s --latency http://127.0.0.1/healthz
其中-t数建议等于 worker 进程数，模拟真实负载分布。
盯住 4 个不可妥协的核心指标
这些指标比“QPS 越高越好”更有决策价值：
-
CPU 使用率：top 中
%us（用户态）持续 >85% 且%sy（内核态）也高，说明可能陷入频繁上下文切换或系统调用瓶颈——这时要检查worker_cpu_affinity是否生效、accept_mutex off是否开启； -
内存与连接状态：
free -h看可用内存是否骤降；ss -i state established | wc -l统计真实 ESTAB 连接数，应接近worker_processes × worker_connections × 0.8（留出缓冲）； -
TIME-WAIT 与重传：
netstat -ant | awk '{print $6}' | sort | uniq -c | sort -n，若TIME-WAIT占比超 30%，需确认net.ipv4.tcp_tw_reuse = 1和net.ipv4.ip_local_port_range是否已调宽； -
Nginx 自身指标：启用
stub_status模块（location /nginx_status { stub_status; }），实时抓取Active connections、Reading/Writing/Waiting分布——Waiting 长期 > Active 的 70%，说明 keepalive 复用率低或后端响应慢拖累前端。
一次闭环调优的典型路径
以 16 核 32G 服务器为例：
- 初始设
worker_processes auto（得 16）、worker_connections 16384、worker_rlimit_nofile 100000； - 压到 12w 连接时发现大量
Too many open files错误 → 检查ulimit -n仅 65535 → 改/etc/security/limits.conf并重启 nginx； - 再压发现 CPU
%sy达 40% → 启用worker_cpu_affinity auto+accept_mutex off→%sy降至 8%； - 最后在 14w 连接下，99% 延迟稳定在 45ms、错误率
