nginx多进程fd分配需验证实际占用是否倾斜：逐个统计worker进程fd数（lsof -p pid）、核对/proc/pid/limits中soft limit是否一致、结合netstat连接数与access_log（含$pid）分析异常根源。
排查 Nginx 多进程架构下各 Worker 进程的文件描述符（FD）分配是否均等，核心不是看“理论均分”，而是验证实际运行中 FD 占用是否存在显著倾斜——因为 Nginx 本身不调度连接到特定 Worker，但系统内核和配置会影响负载分布，进而反映在 FD 消耗上。若某 Worker FD 使用率远高于其他进程，往往意味着它承接了过多连接或存在泄漏，是性能瓶颈或异常的早期信号。
查每个 Worker 进程当前打开的 FD 数量
必须逐个统计 worker 进程的 fd 实际占用，不能只看 master 或平均值：
- 先获取全部 worker PID：
pgrep -f "nginx: worker process" - 对每个 PID 执行：
lsof -p <pid> | tail -n +2 | wc -l</pid>（tail -n +2排除表头） - 或一键汇总并按 PID 分组：
lsof -p $(pgrep -f "nginx: worker process" | tr '\n' ',' | sed 's/,$//') 2>/dev/null | awk '{print $2}' | sort | uniq -c | sort -nr
输出类似 12456 12345 表示 PID 12345 的进程打开了 12456 个文件描述符。对比各 PID 的数值，差异超过 30% 就值得深挖。
比对各 Worker 的软限制是否一致
即使配置了 worker_rlimit_nofile，也要确认每个 worker 进程启动时真正生效的限制值：
- 任选一个 worker PID，执行：
cat /proc/<pid>/limits | grep "Max open files"</pid> - 重复检查 3–5 个不同 worker 进程，确认 “Soft Limit” 列数值完全相同
- 若出现部分进程 soft limit 明显偏低（如 1024），说明该 worker 启动时未继承正确的 ulimit，常见于 systemd 启动未配置
LimitNOFILE，或使用非标准用户启停
结合连接数与请求特征判断是否合理倾斜
FD 不均等未必是问题，需结合业务逻辑判断是否符合预期：
- 用
netstat -anp | grep :80 | grep nginx | awk '{print $7}' | cut -d',' -f1 | sort | uniq -c | sort -nr查看各 worker 绑定的客户端连接数，应与 FD 数趋势基本一致 - 若某 worker FD 高但连接数低，可能是日志、SSL 缓存、临时文件或 upstream keepalive 连接堆积所致
- 若所有 worker 连接数接近但 FD 差异大，重点检查该 worker 是否处理了大量大文件下载、长轮询、HTTP/2 流多但复用不足等高 FD 开销场景
用请求 ID 和 PID 日志辅助归因
在 access_log 中加入 $pid 和 $request_id，可将异常请求直接关联到具体 worker：
- 配置 log_format 包含：
'$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_time $upstream_response_time $pid $request_id'; - 当发现某 worker FD 持续偏高时，筛选其 PID 对应的 access.log，观察是否集中处理特定 URL、User-Agent、或上游分组（如
$upstream_addr） - 配合错误日志中的
connect() failed (24: Too many open files)行，直接定位是哪个 worker 在哪一时刻触达上限
