遭遇多租户云环境下由于 CPU 超卖导致的 Worker 进程时间片被强占引发的转发超时-Nginx-PHP中文网

本质是虚拟层资源不可控与应用层调度未适配叠加所致；需确认超卖（htop、loadavg、throttled日志）、禁用auto改显式vCPU绑定、调低调度敏感度并提升worker_priority、启用keepalive与限流。

遭遇多租户云环境下由于 cpu 超卖导致的 worker 进程时间片被强占引发的转发超时

多租户云环境下，CPU 超卖导致 Nginx worker 进程时间片被强占、进而引发转发超时，本质是虚拟层资源不可控与应用层调度未适配的叠加结果。这不是配置写错了，而是宿主机把“承诺的 vCPU”拆分给了太多租户，你的 worker 线程在争抢中频繁被切出、延迟响应，连接在 upstream 或 client 侧直接超时。

确认是否真由超卖触发

先排除自身配置或业务干扰：

用 htop -H 查看各 worker 线程 CPU 占用——若出现 1 个线程跑满 95%，其余 3 个长期低于 5%，就是典型时间片不均
运行 cat /proc/loadavg，对比 1 分钟负载值与分配的 vCPU 数：若持续 > 2×vCPU，说明宿主机 CPU 已严重过载
查 dmesg | grep -i throttled 或 grep "cpu.*throttle" /var/log/messages，AWS t 系列、阿里云共享型实例常见该日志

禁用 auto 绑定，改用显式 vCPU 掩码

worker_cpu_affinity auto 在超卖环境反而有害——它按物理核逻辑绑定，但虚拟机看到的 CPU 编号是动态映射的，容易错绑或反复迁移。

执行 cat /sys/devices/system/cpu/online 确认实际分配的 vCPU 范围（如 0-3）
设 worker_processes 4，则配：worker_cpu_affinity 0001 0010 0100 1000;
若只分到 2 个 vCPU，必须将 worker_processes 改为 2，否则多余进程只能空转争抢，徒增上下文切换

降低内核调度敏感度 + 提升 worker 优先级

超卖下频繁调度代价极高，需让内核“少管一点”，同时让 Nginx 进程“稍微硬气一点”：

临时调小调度周期：echo 12000000 > /proc/sys/kernel/sched_latency_ns
永久生效：在 /etc/sysctl.conf 加两行：
kernel.sched_latency_ns = 12000000
kernel.sched_min_granularity_ns = 1500000
Nginx 配置中加：worker_priority -5;（避免被宿主机其他进程压制）

减少单请求 CPU 开销，缓解争抢压力

每个请求耗时越短，被抢占的概率就越低，超时风险自然下降：

启用长连接复用：keepalive_timeout 60s; keepalive_requests 1000;
对非必要方法快速拦截，避免进入完整处理流程：
if ($request_method !~ ^(GET|HEAD|POST)$) { return 405; }
检查 upstream 是否启用了 keepalive，避免每次转发都重建连接