轮询策略本身开销极低，千级并发下CPU占用可控；真正影响性能的是网络收发、SSL处理、proxy_pass转发及配套配置（如keepalive、健康检查）是否合理。
直接压测 + 观察 worker 进程 CPU 占用，就能看清千级并发下轮询本身的开销是否可控。轮询策略本身几乎不耗 CPU，真正要盯的是 Nginx worker 的整体负载分布和调度行为是否健康。
用 wrk 模拟千级并发请求
轮询调度逻辑极轻量，但真实压力来自网络收发、SSL 处理、proxy_pass 转发等环节。推荐用 wrk（比 ab 更准）发起稳定千级并发：
- wrk -t4 -c1000 -d30s http://your-nginx-ip/：4 线程、1000 并发连接、持续 30 秒
- 确保后端至少有 2 台服务正常响应，避免因后端卡顿掩盖调度层表现
- 压测期间禁用 gzip、access_log（或写入内存盘），减少干扰项
实时监控 Nginx worker 的 CPU 使用情况
轮询不参与哈希或响应时间采集，所以 CPU 高通常不是它的问题——重点看是不是 worker 进程自身被拖累：
- 运行 top -p $(pgrep nginx | head -n1)，观察单个 worker 的 %CPU 是否稳定在 30% 以内（千级并发下理想值）
- 用 pidstat -p $(pgrep nginx) 1 查看每秒上下文切换次数，若 >5000 次/秒，说明存在软中断或锁争用，需检查 RPS 或 upstream 配置
- 执行 nginx -T 2>/dev/null | grep -A5 "upstream"，确认没误配 ip_hash 或 least_time 等高开销算法
验证轮询是否真正在“低开销运行”
纯轮询的特征是：请求分发快、无状态、不依赖共享内存。可通过两个信号判断它没被带偏：
- 查看 /proc/softirqs 中 NET_RX 行各 CPU 列增长是否均衡（说明网卡队列已分散，worker 不抢资源）
- 统计 access.log 里各后端 IP 的请求数：awk '{print $NF}' access.log | sort | uniq -c | sort -n，偏差控制在 ±3% 内即表明轮询逻辑未受干扰
- 如果发现某 worker CPU 突然飙升而其他正常，大概率是该进程绑核失败或 NUMA 内存访问跨节点，需检查 worker_cpu_affinity 和 numactl 启动方式
排除常见干扰项
千级并发下 CPU 异常升高，90% 以上和轮询无关，而是配套配置没跟上：
- 没配 keepalive 32 导致频繁建连，SYN 包处理吃满一个核
- health check 缺失（如 max_fails=0），故障后端持续收请求，引发大量超时重试和 proxy_next_upstream 折返
- SSL/TLS 握手未复用 session ticket，每次新建连接都做完整非对称加解密
- log_format 含 $request_time 或 $upstream_response_time，触发高精度计时器频繁调用
