确认 Nginx CPU 亲和性配置是否引发其他服务性能下降，需检查 worker_cpu_affinity 是否过度绑定核心、是否预留资源给数据库等关键服务，并结合 ps、htop、pidstat 等工具验证负载分布与响应延迟。
排查 CPU 亲和力（worker_cpu_affinity）配置引发的系统其他服务性能下降，关键在于确认 Nginx 进程是否“过度独占”特定 CPU 核心，从而挤占数据库、缓存、监控等共用服务的计算资源。
确认 Nginx 是否绑定了过多或不当的 CPU 核心
先查当前配置是否超出合理范围：
- 运行
grep worker_cpu_affinity /etc/nginx/nginx.conf，看是否为每个 worker 都分配了独立核心（如 8 个 worker 对应 8 个掩码），且未预留核心给其他关键服务 - 对比
worker_processes数量与实际 CPU 逻辑核数（nproc或lscpu | grep "^CPU(s)"），若两者相等且全部绑定，又同时运行 MySQL、Redis 等 CPU 密集型服务，就容易争抢 - 特别注意：若服务器是多路 CPU（如 2×E5-2650v4），还要考虑 NUMA 架构——跨 NUMA 节点访问内存会显著增加延迟，此时仅靠 CPU 掩码绑定不够，还需配合
numactl启动或调整进程优先级
观察 CPU 分布与服务响应是否存在强关联
用实时工具验证绑定效果及其副作用：
- 执行
ps -eo pid,comm,psr,pcpu --sort=-pcpu | grep nginx，查看各 worker 的 CPU 编号（psr）和 CPU 使用率（pcpu）。若某几个核心长期 95%+ 占用，而其他核心空闲，说明负载不均 - 同时运行
htop，按F2 → Display options → Show custom thread names，再按F5树状视图，观察 MySQL、Redis 等进程是否频繁被调度到已被 Nginx 占满的核心上，出现高上下文切换（cs值飙升）或等待调度（wait时间升高） - 检查
/proc/interrupts中软中断（SI）分布，若集中在少数 CPU，可能因 Nginx 高频事件触发大量软中断，间接拖慢同核其他进程
临时禁用或调整亲和性，做对比验证
不改配置直接测试影响范围：
- 注释掉
worker_cpu_affinity行，设worker_processes auto，重载 Nginx：nginx -s reload - 用
pidstat -t 1 30持续采集 30 秒线程级 CPU 使用，对比前后 MySQL 查询延迟（如pt-query-digest抓取慢日志）、Redis PING 延迟（redis-cli --latency -h 127.0.0.1）是否明显回落 - 若恢复明显，说明原绑定策略过激；可改为“留 2 核专用给数据库”，例如 16 核机器配
worker_processes 14并用掩码跳过 CPU 0 和 1：worker_cpu_affinity 0000000000000011 0000000000000100 ...（共 14 组）
结合系统整体负载判断是否真为亲和性问题
避免误判，需排除其他干扰因素：
- 用
top -1看全局 CPU 使用率中%sy（内核态）是否异常高——若高，更可能是 SSL 日志变量滥用、频繁系统调用或模块缺陷，而非亲和性本身 - 检查
iostat -x 1中%util和await，若磁盘 I/O 等待严重，Nginx 大量 worker 可能因等待日志刷盘而堆积在少数 CPU 上，表面像亲和性问题，实为 I/O 瓶颈 - 确认
error.log是否有 “worker process is shutting down” 频繁出现——这是日志写入阻塞的典型信号，与 CPU 绑定无关，需优先优化日志异步写或关闭高开销字段
