排查Nginx容器性能下降需分层验证：先确认容器是否被CPU/内存配额限速（查docker stats或kubectl top、cgroup cpu.stat、OOM事件），再检查Nginx配置是否适配资源限制（worker_processes、worker_connections、精简模块），最后结合stub_status、ulimit、request_time及Prometheus指标分析真实吞吐与瓶颈。
排查 Nginx 在云原生容器化环境中因资源配额限制导致的性能下降，关键不是“猜瓶颈”，而是按层级验证：先看容器是否被系统限速，再看 Nginx 是否在“天花板”下低效运行。
查容器是否被 CPU 或内存硬限压制
资源限制生效后不会报错，但会静默节流或杀进程。必须主动确认：
- 执行 docker stats <nginx-container>（Docker）或 kubectl top pod <nginx-pod>（K8s），观察 CPU % 是否长期接近 100%、MEM USAGE 是否频繁逼近 LIMIT —— 若是，说明已触顶
- 检查 CPU 节流情况：cat /sys/fs/cgroup/cpu/cpu.stat（进容器执行），关注 throttled_periods 和 throttled_time；非零值即表示被 cgroups 强制暂停过
- 查 OOM 事件：kubectl describe pod <pod-name> 看 Events 中是否有 OOMKilled；或 grep -i "killed process" /var/log/syslog（宿主机日志）
验 Nginx 配置是否适配容器规格
即使容器有 2 核 512Mi 内存，Nginx 默认配置仍可能创建过多 worker 或连接，加剧争抢：
- 确认 worker_processes：不能写 auto，应设为与容器 limits.cpu 向下取整一致（如 limits.cpu=1.5 → 设为 1；limits.cpu=2 → 可设 2）
- 计算 worker_connections：每个连接约占 2KB 内存；若内存 limit 为 384Mi，预留 128Mi 给系统/日志，则可用约 256Mi → 最大支持约 131,072 连接；搭配 2 个 worker，单 worker 设 8192 更稳妥
- 进容器执行 nginx -V 2>&1 | grep -o 'with.*modules'，确认未启用 perl、xslt 等冗余模块；生产环境建议用 nginx:alpine-slim 镜像
看连接与请求的实际承载能力
资源够不代表处理能力强，需结合 Nginx 自身状态验证吞吐是否达标：
- 启用 stub_status 模块（在 server 块中加 location /nginx_status { stub_status; }），访问 curl http://localhost/nginx_status 查看 Active connections 和 Reading/Writing/Waiting 分布 —— Waiting 数持续高，常说明 worker_connections 不足或 upstream 响应慢
- 检查 ulimit -n（进容器执行）：若低于 worker_connections × worker_processes，连接会直接失败；应在 Dockerfile 中用 ulimit -n 65536 或 K8s 的 securityContext: { runAsUser: 101, privileged: false } 配合 resources.limits 一并设置
- 对比 access.log 中 $request_time：若大量请求耗时接近 proxy_read_timeout 或 keepalive_timeout，说明上游延迟或 Nginx 本身调度不及时
比对监控指标找异常拐点
单次排查易遗漏趋势问题，需关联时间维度分析：
- 用 Prometheus 查询 container_cpu_cfs_throttled_periods_total{container="nginx"}，看节流次数是否随流量增长陡升；节流率 > 5% 就需调高 CPU limit 或优化代码
- 查 container_memory_working_set_bytes{container="nginx"} 曲线：若内存用量贴着 limit 波动，且伴随 502/504 错误增多，大概率是内存不足触发了连接中断或缓存失效
- 结合 nginx_http_requests_total 和 container_network_receive_bytes_total，算出平均请求大小 —— 若突增，可能是攻击或上传行为未受 client_max_body_size 限制，悄然吃光连接资源
