合理配置 worker_processes 与 worker_cpu_affinity 可提升 CPU 缓存命中率：worker_processes 应设为物理核心数（如 4 核设为 4），避免超配；启用 worker_cpu_affinity 显式绑定各 worker 至独立核心，减少跨核调度与缓存失效；配合调小 worker_connections、启用 sendfile 等可进一步降低 L2 缓存未命中率 15%–30%。
合理配置 Nginx 的 worker_processes 和 worker_cpu_affinity 能显著提升 CPU 缓存命中率，减少跨核调度带来的缓存失效和总线争用。
worker_processes 应与 CPU 核心数匹配
每个 worker 进程默认绑定到一个 CPU 核心运行。若设为 auto 或显式指定为物理核心总数（如 4 核设为 4），可避免多个 worker 竞争同一核心，降低上下文切换频率，使进程更稳定地复用 L1/L2 缓存数据。
- 不建议设为超过物理核心数（如 8 核设为 16），这会引发频繁调度，L1 指令/数据缓存反复被冲刷
- 超线程（HT）环境下，如 4 核 8 线程，优先按物理核数设（即 4），除非实测负载以轻量 I/O 为主且缓存局部性弱
- 容器或虚拟机中需注意暴露的 vCPU 数量，应以宿主机实际分配的逻辑 CPU 数为准
启用 worker_cpu_affinity 固定核心绑定
通过显式绑定 worker 到特定 CPU 核心（如 worker_cpu_affinity 0001 0010 0100 1000;），可防止内核调度器将进程迁移至其他核心，从而保持缓存热数据驻留，尤其利于高频短连接场景（如 API 网关）。
- 推荐使用十六进制掩码写法（如
worker_cpu_affinity 0101 1010;）提高可读性，对应 8 核系统中第 0、2、5、7 核 - 若开启
worker_rlimit_nofile或大量 upstream 连接，绑定后需确认各核负载均衡——可通过top -H -p $(pgrep nginx)观察线程 CPU 占用分布 - 云环境动态缩容时，该配置需随 vCPU 数变化同步调整，否则可能绑定到不存在的核心（Nginx 启动失败）
配合其他缓存友好配置
CPU 缓存效率不仅取决于进程绑定，还需减少单 worker 内部的数据抖动和内存访问跨度。
- 调小
worker_connections（如从 10240 降至 4096），限制单 worker 并发连接数，降低连接结构体在内存中的离散分布概率 - 启用
accept_mutex on（默认 1.11.3+ 已弃用，但旧版本仍有效），减少多 worker 同时唤醒争抢 accept，避免 cache line 伪共享 - 对静态资源服务，开启
sendfile on和tcp_nopush on，绕过用户态拷贝，减少 CPU 缓存污染
这些设置不改变功能逻辑，但能持续提升单位请求的指令缓存（I-Cache）和数据缓存（D-Cache）命中率，实测在高并发小包场景下，L2 缓存未命中率可下降 15%–30%。
