worker_processes 应严格按 Kubernetes Pod 的 resources.limits.cpu 整数值设置，如 limits.cpu: "2" 则设为 2；需配合 worker_cpu_affinity auto、worker_rlimit_nofile 65535 和足够大的 worker_connections，避免 auto 误读宿主机核数或超线程干扰。
在微服务网关架构中，worker_processes 不应简单设为“CPU核数”或盲目用 auto，而需紧扣网关的典型负载特征：高并发短连接、TLS终止密集、上游动态发现、频繁 header/rewrite 处理（尤其使用 OpenResty 或 Nginx Plus），并兼顾容器化与资源隔离约束。
按 Kubernetes Pod 分配的 vCPU 数显式设置
微服务网关几乎全部运行于 K8s 中，此时 worker_processes auto 极易误读宿主机 CPU 数——它看不到 cgroups 限制。必须与 Pod 的 resources.limits.cpu 严格对齐：
- 若配置
limits.cpu: "2"（即 2 个 vCPU），则写worker_processes 2; - 若为
"1500m"（1.5 vCPU），Nginx 不支持小数，应向上取整为2，但需压测验证是否过载；更稳妥做法是申请整数 vCPU（如"2"）并固定配置 - 避免用
requests.cpu做依据——它仅用于调度，不约束实际可用算力
优先匹配物理核，而非逻辑线程
即使 K8s 分配了 4 个 vCPU，若底层是 8c16t 物理机，这 4 个 vCPU 仍映射到 4 个物理核心（非超线程伪核）。因此：
- 不采用
lscpu | grep "CPU(s):"得到的 16，也不依赖容器内nproc（常被 cgroups 截断） - 以 K8s 分配值为唯一可信来源；若需确认底层拓扑，应在节点维度通过
lscpu | awk '/Core\(s\) per socket/ || /Socket\(s\)/'计算物理核总数，再结合 CPU Manager 策略（如static）判断调度粒度 - 超线程对网关类 I/O+轻计算混合负载收益甚微，反而可能因 L1/L2 缓存争用降低 TLS 握手吞吐
结合网关典型负载类型微调数值
微服务网关不是纯静态服务，其行为介于 I/O 与轻 CPU 密集之间：
- HTTPS 终止（RSA/ECC 握手、session resumption）、gzip 压缩、JWT 验签、Lua 路由逻辑均消耗 CPU，但单请求耗时通常
- 大量短连接（健康检查、API 调用）、频繁 upstream 切换（服务发现）、header 修改带来可观上下文切换压力
- 建议起始值：设为分配 vCPU 数的 100%～125%（如 4 vCPU →
worker_processes 4或5），再通过vmstat 1观察cs（每秒上下文切换）是否持续 > 50k；若过高，回调至 100% - 若启用大量 Lua 模块（如 authz、rate-limiting with shared dict），且
top显示单 worker CPU 占用长期 >80%，可尝试worker_processes = vCPU 数 + 1，但必须同步开启worker_cpu_affinity避免跨核调度
必须配套生效的三项关键参数
只调 worker_processes 几乎无效，以下三者须同步落地：
-
绑定物理核：
worker_cpu_affinity auto;（Nginx ≥1.9.10）自动跳过超线程对称核；若版本较老或需精确控制，按 vCPU 数生成掩码（如 4 vCPU →0001 0010 0100 1000） -
提升文件描述符上限：
worker_rlimit_nofile 65535;，且确保容器内ulimit -n≥ 此值（K8s 中通过securityContext.ulimits设置） -
对齐连接数容量：events 块中
worker_connections应满足worker_processes × worker_connections ≥ 预期峰值并发连接数；网关常见值为 8192～16384，而非默认 1024
