如何配置 worker_cpu_affinity 结合硬件指令集压榨网关层缓存分发的性能极限-Nginx-PHP中文网

worker_cpu_affinity auto是当前最可靠方式，自动按物理核顺序分配、避开超线程争抢与numa跨节点问题，需先用lscpu确认真实cpu拓扑再启用。

如何配置 worker_cpu_affinity 结合硬件指令集压榨网关层缓存分发的性能极限

直接用 worker_cpu_affinity auto 是当前最可靠的方式，尤其在网关层承担 HTTPS 反代、高频缓存分发的场景下。它自动跳过超线程逻辑核，按物理核顺序分配，避免手动配错掩码导致 Worker 挤在同一核心或跨 NUMA 节点，真正把硬件指令集和缓存局部性优势用足。

网关性能瓶颈常不在计算本身，而在缓存元数据访问延迟与 TLB 刷新抖动。必须明确服务器真实 CPU 架构：

运行 lscpu | grep -E "(CPU$s$|Core|Socket|NUMA)" 查清物理核数、是否开启超线程、NUMA 节点分布
若为双路 CPU（如 2×16 核）且启用 NUMA，不建议用 auto，应显式限定单节点内核，例如只绑 node0 的前 8 核：worker_cpu_affinity auto 000000ff;
若为单路 8 核 + HT（共 16 逻辑 CPU），auto 默认只用前 8 个物理核，天然避开超线程争抢，可直接采用

CPU 绑定让 worker 固定在某核运行，但若共享内存区（如 keys_zone）跨 NUMA 节点、或大小不合理，L3 缓存仍无法高效服务缓存索引查询：

proxy_cache_path 的 keys_zone 大小按预期 key 数 × 300 字节估算，512m 是常见安全值；过大易碎片，过小触发频繁 LRU 清退
加 use_temp_path=off，防止响应体先写临时文件再 move，消除额外 IO 和 inode 锁竞争
启用 open_file_cache max=65535 inactive=60s，减少 stat() 系统调用，对大量小缓存对象（如图标、JS 片段）效果显著

现代 CPU（如 Intel Ice Lake / AMD Zen4）对缓存行对齐、预取行为更敏感，需同步调整 Nginx 内存使用习惯：

确保 worker_processes 等于物理核数（非逻辑核），避免多 worker 争抢同一 L2 缓存域
关闭未启用模块（如 perl、xslt、geoip2），减小 worker 进程常驻内存 footprint，腾出更多 L3 缓存给 proxy_cache slab 和哈希表
若启用 Brotli 或 OpenSSL 3.0+，确认已编译支持 AVX2/SHA-NI 指令，相关压缩/验签操作会自动加速，降低单请求 CPU 占用，间接提升缓存吞吐密度

reload 配置后不能只看 nginx -t 或日志，要实测调度行为与缓存路径表现：

执行 ps -eo pid,args,psr | grep 'nginx: worker'，检查每个 worker PID 对应的 PSR 是否稳定落在不同物理核编号上，且不重复
用 pidstat -t -p $(pgrep nginx) 1 观察各 worker 线程的 %usr 和 %sys 分布，若某核持续高 %sys（>15%），可能 open_file_cache 或共享内存锁存在争用
统计 $upstream_cache_status 中 HIT 与 EXPIRED 比例变化，注意：命中率上升 ≠ 性能提升，还需结合 p99 延迟下降幅度判断是否真正释放了缓存潜力