nginx高并发下worker句柄分配不均，核心是查“该关没关、被卡住”，需从进程行为、内核限制、配置协同三方面交叉验证：先确认是否真不均（单worker句柄超其他3倍且不回落），再查各worker limits是否一致、file-nr是否逼近上限，最后排查open_file_cache、access_log变量路径、proxy_buffering off等滞留配置及cpu亲和性导致的请求倾斜。
排查 Nginx 高并发下 worker 进程句柄分配不均，核心不是看“谁开得多”，而是查“谁该关没关、谁被卡住了”。这种不均往往不是随机波动，而是由连接生命周期错配、系统资源调度偏差或配置隐性冲突导致的持续性堆积。需从进程级行为、内核层限制、配置协同三方面交叉验证。
确认是否真存在“分配不均”，而非整体耗尽
先排除误判：句柄数在各 worker 间差异大，不等于异常。正常高并发下，因请求到达时间、后端响应延迟、SSL 握手节奏不同，各 worker 句柄数本就会有 ±20% 波动。真正要警惕的是：
- 某个 worker 的 lsof -p PID | wc -l 持续高于其他 worker 3 倍以上，且 5 分钟内不回落
- 该 worker 的 /proc/PID/fd/ 下大量残留 socket:[xxx] 或 /tmp/nginx_temp_xxx 类临时文件句柄
- error.log 中对应 PID 频繁出现 accept() failed (24: Too many open files)，而其他 worker 完全没有
检查 worker 进程是否被系统级限制实际“锁死”
句柄不均常源于底层限制未对齐，导致部分 worker 在启动时就继承了更低的 soft limit：
- 用 cat /proc/$(pgrep -f "nginx: worker" | head -n1)/limits | grep "Max open files" 分别查每个 worker 的实际软硬限制，确认是否全部一致
- 若数值不同，说明 systemd 或 ulimit 设置未生效到全部子进程——重点检查 systemd 的 LimitNOFILE 是否覆盖了所有 worker（尤其使用 worker_processes auto 时）
- 查看 /proc/sys/fs/file-nr 中 allocated 值是否逼近 file-max：若系统总池子快枯竭，内核会优先向已占用少的 worker 分配新 fd，加剧不均
定位配置中导致句柄滞留的关键模块
很多“不均”本质是某些 worker 更早处理了特定类型请求，而这些请求触发了易滞留句柄的配置项：
- open_file_cache inactive 时间过长：若某 worker 先处理了一批图标、JS 等短命静态资源，且 inactive 设为 300s，它就会独占这批 fd 长达 5 分钟，其他 worker 无法复用
- access_log 路径含变量（如 $host、$request_uri）：当不同 worker 收到的 host 组合差异大，各自打开的日志文件数线性增长，且不会跨进程共享
- proxy_buffering off + 大响应体：某个 worker 恰好承接了多个慢速大文件下载，每个都会预分配几 MB 缓冲区及关联 fd，释放又依赖后端 FIN，极易堆积
验证连接分发与 CPU 亲和性是否形成负反馈
句柄不均有时是负载不均的结果，而非原因：
- 执行 ps -eo pid,comm,psr,pcpu --sort=-pcpu | grep nginx，看高句柄 worker 是否长期绑定在同一 CPU 核心上
- 检查是否启用了 worker_cpu_affinity auto；若未启用，Linux CFS 调度器可能将密集请求持续派给同一 worker（尤其在短连接高频场景）
- 观察 netstat -ant | awk '$4 ~ /:80$/ {print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -5：若前 5 名 IP 都来自同一 NAT 网关，它们全被哈希到同一个 worker，其句柄自然远超其他
