Nginx性能优化需匹配硬件、内核与业务，worker_processes设为物理核心数（auto最佳），worker_connections需满足ulimit限制，理论并发=进程数×连接数，keepalive_timeout建议60–75秒并配合keepalive_requests防资源滞留。
Linux 下 Nginx 性能优化不是靠堆参数，而是靠理解每个参数背后的资源约束与系统协同逻辑。关键在于匹配硬件能力、内核限制和业务特征，而非盲目调高数值。下面按层级说明核心参数的计算依据与合理取值标准。
worker_processes 与 CPU 资源匹配
该参数决定 Nginx 启动多少个 worker 进程，直接影响并发处理能力和 CPU 利用效率。
-
理论取值：通常设为物理 CPU 核心数（非超线程数），高 I/O 密集型场景可设为
cpu_cores × 1~2 -
推荐写法：
worker_processes auto;—— Nginx 自动识别物理核心数，避免人工误判 -
注意点：超过物理核心数后，进程上下文切换开销可能抵消并发收益；若启用了
worker_cpu_affinity，必须确保掩码位数与进程数一致
worker_connections 与文件描述符上限联动
单个 worker 进程能同时处理的最大连接数，其实际生效受系统级文件描述符限制制约。
-
计算公式：
系统 ulimit -n ≥ worker_processes × worker_connections × 2（×2 是因每个连接至少占用 1 个 socket 描述符 + 1 个文件句柄，如静态文件） - 常见取值：65535 或 16384（取决于系统配置能力），不建议直接写 65535 若未同步提升系统限制
-
配套操作：
- 在
/etc/security/limits.conf中设置：* soft nofile 100000和* hard nofile 100000 - 在
nginx.conf全局块中加：worker_rlimit_nofile 100000; - 验证命令：
cat /proc/$(pgrep nginx)/limits | grep "Max open files"
- 在
总并发能力估算与瓶颈识别
Nginx 理论最大并发连接数由两个参数共同决定，但真实承载能力还受限于内存、网络栈和后端服务响应速度。
-
理论并发上限：
worker_processes × worker_connections - 内存消耗参考：每个空闲连接约占用 2.5–4 KB 内存；活跃连接（含请求头、缓冲区等）可能达 10–20 KB
-
实际建议：生产环境建议按理论值的 60%~70% 设定监控告警阈值，例如 8 核服务器配
worker_processes 8; worker_connections 16384;，则理论并发为 131072，但应将连接数告警线设在 80000 左右
keepalive_timeout 与客户端行为适配
长连接保持时间并非越长越好，需平衡复用收益与连接堆积风险。
- 取值标准：一般设为 60–75 秒，略高于典型 HTTP 请求往返时间（RTT）+ 后端处理时间
-
配套参数：
keepalive_requests 10000;（单连接最多请求数），防止一个慢连接长期占用资源 -
慎用场景：移动端弱网环境下，客户端可能异常断连但未发 FIN，过长的 timeout 会导致连接滞留；此时可结合
keepalive_disable mobile或缩短 timeout 至 30s
