在一次突如其来的活动流量中，我们的网站访问量在短时间内暴涨至百万级 PV 峰值。虽然业务部署在香港的高性能服务器上，但 Nginx 网关瞬间被压垮，大量请求502错误涌现。经过事后排查，我们发现瓶颈并非在应用层，而是在 Nginx 的 worker 参数和连接池配置不合理上。以下是我完整的调优实操过程及技术细节，希望对类似场景下的工程落地有所帮助。
一、服务器环境基础
我们采用的是 A5 数据香港沙田 BGP 高防服务器，配置如下：
- CPU：Intel Xeon E-2388G（8核16线程）
- 内存：64GB ECC DDR4
- 硬盘：NVMe RAID10 SSD 阵列
- 带宽：100Mbps CN2 GIA + 多段 BGP 动态优化线路
- 操作系统：CentOS 7.9 / Kernel 5.4 LTS 自编译优化内核
部署架构中，Nginx 作为前端反向代理，后接应用网关与 Redis 缓存层。
二、问题复盘与瓶颈定位
通过 top 和 netstat -an | grep :80 | wc -l 观察发现：
- CPU Idle 较高，Nginx 并未充分使用所有核心；
- worker_connections 明显不足，大量请求被拒绝；
- accept_mutex 同步竞争过频，worker 线程间阻塞严重；
- 系统 ulimit 打开文件数过低，影响并发连接池容量。
- 初步判断：Nginx 并未充分利用多核处理能力，同时连接池上限严重制约了吞吐。
三、Nginx 核心参数调优
1. worker_processes：启用多核能力
worker_processes auto;
这个参数设置为 auto，Nginx 会自动检测物理 CPU 核数。也可手动设为 8 或 16，视核心数而定。
2. worker_cpu_affinity：绑定 CPU 核心
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
通过该参数可避免多个进程调度到同一核上，降低上下文切换。
3. worker_connections：最大连接数
events {
worker_connections 65535;
use epoll;
multi_accept on;
accept_mutex off;
}
- 65535 理论上允许每个 worker 同时处理 6 万连接（需配合 ulimit）。
- use epoll 启用高性能事件模型；
- multi_accept on 允许一次性接收所有连接；
- accept_mutex off 禁用锁竞争，提高多 worker 并发性能。
四、系统层优化（连接池支撑）
1. 增大文件描述符限制
ulimit -n 655350
并在 /etc/security/limits.conf 中添加：
* soft nofile 655350
* hard nofile 655350
确保每个 Nginx worker 能处理海量并发连接。
2. sysctl 网络参数优化
编辑 /etc/sysctl.conf 添加如下内容：
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_max_tw_buckets = 2000000
然后执行：
sysctl -p
这些参数确保：
- TCP SYN 队列足够长；
- 快速回收 TIME_WAIT 连接；
- 保证端口池足够支撑高并发短连接。
五、Nginx 配置完整示例（节选）
worker_processes auto;
worker_rlimit_nofile 655350;
events {
use epoll;
worker_connections 65535;
multi_accept on;
accept_mutex off;
}
http {
include mime.types;
default_type application/octet-stream;
keepalive_timeout 30;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
gzip on;
gzip_disable "msie6";
upstream backend {
server 127.0.0.1:8080;
keepalive 64;
}
server {
listen 80 default_server;
server_name localhost;
location / {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
}
}
}
六、压测验证与结果回归
我们使用 wrk 工具进行压力测试：
wrk -t8 -c20000 -d60s http://yourdomain.com/
调优前：
- 并发连接 5000 即明显出现超时；
- CPU 使用率不均衡，部分核心负载飙升。
调优后：
- 支持单节点 20,000+ 并发稳定响应；
- 峰值 100 万 PV/h 不再抖动，502 错误清零；
- CPU 多核分布均衡，系统 load 稳定维持在 2~4。
七、总结与经验建议
- worker 参数并非越大越好，应结合 CPU 核数调配；
- 连接数上限需同时调整 Nginx、系统内核与 ulimit，缺一不可；
- epoll 与 multi_accept 的协同使用是应对高并发的关键；
- 提前压测找瓶颈，Nginx 是高并发网关中的第一道防线；
- 如果有 TLS，则 SSL 会带来另一重 CPU 压力，需进一步优化握手缓存与 TLS 会话重用机制（本文未展开）。
这套调优方案已在多个高并发项目中验证有效，尤其适用于部署在高性能香港服务器上的门户、电商、短视频和API服务。配合香港地区良好的国际出口质量，可以充分释放 Nginx 的性能上限。
