Nginx性能瓶颈常源于worker_processes和worker_connections配置不合理：前者应据负载类型（IO密集或上游延迟）在CPU核心数附近调整，避免过多导致上下文切换；后者须≤ulimit -n的70%~80%，并配合调优内核参数如net.core.somaxconn、fs.file-max等，再通过ss、stub_status和压测验证。

Linux下Nginx的性能瓶颈，往往不在于CPU或磁盘，而在于worker进程数和每个worker能处理的连接数没配合理。这两个参数直接决定Nginx并发能力上限，调得太高浪费资源，太低压根跑不满硬件。

worker_processes：别盲目设成auto

这个参数控制Nginx启动几个worker进程。常见误区是直接写worker_processes auto;——它会按CPU核心数起进程，但实际是否最优，得看负载类型。

• 如果业务主要是静态文件服务、IO等待多（比如大量小图、JS/CSS），worker数接近CPU核心数通常合适；
• 如果后端是高延迟上游（如慢API、数据库直连），单个worker可能长期阻塞，适当增加worker数（比如核心数×1.5）反而能提升吞吐；
• 但超过CPU核心数太多（比如8核配16个worker），会导致频繁上下文切换，反而降低性能；
• 建议先用worker_processes 1;压测基线，再逐步加到核心数，观察top中%wa（IO等待）和%si（软中断）是否异常升高。

worker_connections：不是越大越好

它定义每个worker进程最多同时处理多少个连接。但真实可用值受系统级限制制约，不能只看这个配置。

• 实际最大连接数 = worker_processes × worker_connections，但受限于ulimit -n（单进程最大文件描述符数）；
• 必须确保worker_connections ≤ ulimit -n，否则Nginx启动时会报错或静默降级；
• 还要预留描述符给日志、上游连接、临时文件等，一般建议worker_connections设为ulimit -n的70%~80%；
• 例如ulimit -n是65536，那worker_connections 50000比65535更稳妥。

配套必须调的系统参数

Nginx配置只是上层，底层内核参数不跟上，再好的配置也白搭。

• net.core.somaxconn：监听队列长度，至少调到65535，避免SYN包被丢弃；
• net.ipv4.tcp_max_syn_backlog：SYN半连接队列，同步调高；
• fs.file-max：系统级最大文件句柄数，应大于所有Nginx worker需要的总和；
• 记得在/etc/security/limits.conf里给nginx用户设nofile软硬限制，否则ulimit设置不生效。

验证是否调到位的简单方法

别光看配置文件，用真实指标说话：

• 用ss -s看当前socket统计，重点关注total和used是否接近上限；
• 查Nginx状态页（需启用stub_status模块），观察Active connections峰值是否稳定在预期范围内；
• 压测时用watch -n1 'ps aux | grep nginx | grep -v grep'看worker进程RSS内存是否暴涨——可能是连接数设太高导致内存吃紧；
• 如果nginx -t通过但日志里反复出现* * * * no live upstreams while connecting to upstream，很可能是上游连接耗尽，要检查upstream keepalive配置而非单纯调大worker_connections。