排查nginx ingress controller的worker性能瓶颈，核心是定位cpu、连接数、请求延迟三者失衡点：通过prometheus指标交叉验证cpu是否超80%、连接数是否逼近上限、upstream响应快但整体延迟高，确认后优先调优worker_processes、worker_connections、ssl_session_cache等参数，而非盲目扩副本。
排查 Nginx Ingress Controller 的 worker 性能瓶颈，核心是定位 CPU、连接数、请求延迟三者之间的失衡点。默认配置下，worker 进程常因 SSL 处理、连接未复用或缓冲区过小而成为吞吐瓶颈，而非资源不足。
确认是否为 worker 层瓶颈
先通过 Prometheus 指标交叉验证：
- nginx_ingress_controller_nginx_process_cpu_seconds_total 持续高位（单 worker > 80% CPU）且伴随 nginx_ingress_controller_request_duration_seconds p95 显著上升 → 典型 CPU 密集型瓶颈
- nginx_ingress_controller_nginx_process_connections 接近 worker_connections × worker_processes 上限，同时 nginx_ingress_controller_nginx_process_resident_memory_bytes 稳定 → 连接层压满，需调大连接池
- 对比 upstream_response_time 和 request_duration：若前者低但后者高，说明耗时在 Nginx 本体（如 rewrite、SSL 握手），而非后端服务
优化 worker 进程与连接模型
避免盲目增加副本，优先调整进程级参数：
- 显式设置 worker_processes 为 CPU 核数（如 4c 配置设为
4），禁用auto（避免容器内核感知偏差） - 调高 worker_connections 至 16384 或更高（需同步调大系统
fs.file-max和net.core.somaxconn） - 启用 multi_accept on，让单个 worker 尽可能一次接受多个就绪连接
- 关闭 accept_mutex（Kubernetes 场景下并发连接稳定，mutex 反成锁竞争点）
针对性缓解常见 worker 压力源
SSL 和重写是高频“CPU 杀手”，需专项处理：
- HTTPS 流量超 70% 时，启用 ssl_session_cache shared:SSL:256m 和 ssl_session_timeout 10m，大幅减少握手开销
- 禁用旧 TLS 协议（
ssl_protocols TLSv1.2 TLSv1.3）和低效加密套件（如含RC4、3DES的） - 重写规则尽量用 location 前缀匹配 替代正则；必须用正则时，加
^~前缀提前终止匹配 - 移除非必要 Lua 脚本或注解（如复杂 header 修改、动态鉴权），改由上游服务处理
验证调优效果的关键指标
调参后不看单点数值，而看组合趋势：
- 相同 QPS 下，worker CPU 使用率下降 30%+，且 p95 延迟收窄至 200ms 内
- active connections 稳定在总连接池的 60–70%，无持续堆积或突增回落
- nginx_ingress_controller_requests{status=~"2..|3.."} / nginx_ingress_controller_requests 成功率保持 ≥ 99.95%
