Nginx Worker进程绑定CPU核心可提升缓存局部性与吞吐量；通过worker_cpu_affinity指令配置亲和性，推荐auto模式；需匹配物理核心数、预留关键服务核心，并验证Cpus_allowed_list字段确认绑定生效。
在Nginx多进程模型中，Worker进程默认由操作系统调度，可能频繁跨CPU核心迁移，导致缓存失效、上下文切换开销增大。通过绑定Worker进程到固定CPU核心，可显著提升缓存局部性与吞吐量，尤其在高并发、低延迟场景下效果明显。
理解Worker进程与CPU亲和性
Nginx启动后，主进程（master）负责管理，多个Worker进程实际处理请求。每个Worker是独立的单线程进程，不共享内存，天然适合绑定到特定CPU核心。Linux提供了CPU亲和性（CPU affinity）机制，可通过worker_cpu_affinity指令让Nginx在启动时自动设置进程与核心的绑定关系。
配置worker_cpu_affinity实现核心独占
在nginx.conf的events块或全局块中配置该指令，格式为按Worker序号对应二进制掩码：
- 双核机器（2个Worker）： worker_cpu_affinity 10 01; → 第1个Worker绑CPU0，第2个Worker绑CPU1
- 四核机器（4个Worker）： worker_cpu_affinity 1000 0100 0010 0001;
- 更简洁写法（自动分配）：worker_cpu_affinity auto;（Nginx 1.9.10+支持，推荐用于常规部署）
- 若Worker数少于核心数，可跳过部分核心，例如4核配2 Worker：worker_cpu_affinity 1000 0001;，避开中间核心减少干扰
验证绑定是否生效
配置后重载Nginx，用以下命令确认实际绑定状态：
- 查Worker进程PID：ps -eo pid,comm,args | grep nginx | grep -v master
- 查某PID绑定的核心：taskset -cp
- 观察/proc/
/status中的Cpus_allowed_list字段，应显示唯一核心编号 - 压力测试时用htop（F2 → Columns → 添加PROCESSOR列），直观查看各Worker运行在哪颗核心
注意事项与调优建议
盲目绑定可能适得其反，需结合硬件与负载特征调整：
- 确保worker_processes设为auto或明确等于物理核心数（非超线程数），避免Worker数超过核心数造成争抢
- 若服务器同时运行数据库等其他关键服务，预留部分核心不绑定Nginx，避免资源抢占
- 启用worker_rlimit_nofile并调高文件描述符限制，防止因绑定后连接堆积在单核引发瓶颈
- 对于NUMA架构服务器，还需考虑内存节点亲和性（如配合numactl启动），但Nginx原生不支持，需外部封装
合理配置CPU亲和性不是“一劳永逸”，而是性能调优中见效快、成本低的关键一步。只要匹配真实硬件拓扑与业务流量特征，就能让每个Worker稳定发挥对应核心的全部算力。
