Nginx反向代理性能极限需协同调优worker_cpu_affinity与CPU物理拓扑、指令集及流量特征；优先绑定独立物理核而非逻辑核，auto模式更健壮，须同步调优worker_rlimit_nofile、epoll、upstream keepalive等硬指标。
要让 Nginx 在网关层反向代理场景中逼近性能极限，worker_cpu_affinity 不是“一开就快”的开关，而是必须与 CPU 物理拓扑、指令集能力、流量特征协同调优的关键环节。它真正起效的前提是：worker 进程数已合理设置、系统无 I/O 或锁瓶颈、且绑定策略真实匹配底层硬件能力。
先看清物理核与超线程的真实关系
逻辑核数 ≠ 物理算力。超线程（HT）会让 lscpu 显示双倍逻辑 CPU，但两个逻辑核共享同一物理核的 L1/L2 缓存和执行单元。盲目按 8 个逻辑核配 8 个 worker 并全绑不同逻辑核，反而引发执行单元争抢。
- 运行
lscpu | grep -E "(CPU\(s\)|Core|Socket|Thread)"，确认物理核总数（Core(s) per socket × Socket(s)）和线程数（Thread(s) per core） - 若 HT 开启（Thread(s) per core = 2），优先将每个 worker 绑定到独立物理核，而非所有逻辑核
- 例如 4 物理核 + HT = 8 逻辑核，推荐设
worker_processes 4+worker_cpu_affinity auto，Nginx 1.9.10+ 会自动跳过超线程对称核 - BIOS 中关闭 HT 后实测吞吐，有时更稳——尤其当 upstream 是 TLS 计算密集型或高延迟服务时
用 auto 模式起步，再按需收紧范围
手动写十六进制掩码易出错，也难适配云环境（如 vCPU 数量虚高但物理资源受限）。auto 是更健壮的起点。
-
worker_cpu_affinity auto;—— 自动按物理核顺序分配，每个 worker 独占一个物理核，L1/L2 缓存局部性最优 -
worker_cpu_affinity auto 00001111;—— 限制只使用前 4 个逻辑 CPU（对应前 2 或 4 物理核），适合容器中限定资源配额的场景 - 不建议混用：比如
worker_processes 8但只给 4 个掩码值，剩余 worker 会 fallback 到默认调度，失去控制意义
必须同步调优的硬指标，防止 CPU 绑定失效
CPU 亲和性只是拼图一角。若以下任一条件不满足，绑定再准也白搭：
-
worker_rlimit_nofile必须设够：至少等于ulimit -n，否则连接数上不去，worker 长期空转 -
events { use epoll; worker_connections 65535; multi_accept on; }—— epoll 是 Linux 下高并发事件驱动基石；worker_connections要与worker_processes协同，总连接能力 = 两者乘积 - upstream 连接复用：开启
keepalive 32; keepalive_requests 1000;，减少 TLS 握手与连接重建开销 - 避免干扰调度：不建议再设
worker_priority或自定义sched_setaffinity脚本，Nginx 自身绑定已足够
验证是否真正生效的三步检查法
改完配置 reload 后，别只信日志，实打实看进程状态：
- 查当前运行核：
ps -eo pid,args,psr | grep 'nginx: worker'—— 每个 PID 对应的 PSR 列应是不同数字（如 0、1、2、3），且不重复 - 查亲和性掩码：
taskset -cp $(pgrep -f "nginx: worker" | head -1)—— 显示类似pid 12345's current affinity list: 0 - 查缓存局部性效果：用
perf stat -e cache-references,cache-misses,cpu-cycles,instructions -p $(pgrep -f "nginx: worker" | head -1)对比绑定前后 L1/L2 缓存命中率变化
