服务器nginx进程数开多少合适，会影响并发性能吗？

Nginx可以开启的进程数量没有固定上限，瓶颈取决于服务器CPU的核心数和实际负载类型，多数情况下worker_processes设置为等于或略大于CPU核心数即可获得最优性能。

Nginx使用Master-Worker多进程模型，Master进程负责读取配置和调度Worker，Worker进程真正处理客户端请求，这个设计让Nginx在高并发场景下保持稳定,进程数的设置直接影响资源利用率和响应速度。

加载中

Nginx 性能优化有这篇就够了！

D

DevOps架构师阿良

4569--

原视频地址

配置worker_processes参数

Nginx进程数由nginx.conf配置文件中的worker_processes指令决定，常见的配置方式有三种：设置为auto自动识别、指定固定数字、设为CPU核心数的倍数。

查看服务器CPU核心数的标准命令：

grep -c processor /proc/cpuinfo

该命令返回的数字就是当前服务器的逻辑核心数，在2核4线程的云服务器上，返回值通常是4，将worker_processes设置为auto,Nginx会自动检测并将Worker进程数匹配到可用核心数。

手动配置通常在配置文件的全局段修改：

worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;

worker_rlimit_nofile 65535;
events {
    worker_connections 10240;
    use epoll;
}

worker_rlimit_nofile设置单进程可打开的文件描述符上限，worker_connections定义单个Worker进程能同时保持的最大连接数，两者的乘积总和决定了Nginx处理并发请求的理论上限,这个值需要结合系统ulimit限制做匹配修改：

ulimit -n

返回的数字若低于你所期望的并发连接数，需要通过修改/etc/security/limits.conf文件提升系统级限制。

进程数决策的真实评估维度

实际确定进程数，需要考量三个维度：CPU核心数、业务类型、内存大小。

CPU核心数是首要依据，Worker进程本质上是事件循环加异步I/O的组合体，每个Worker在一个时刻只能占用一个CPU核心执行计算，进程数超过核心数，CPU会在多个进程间做上下文切换，增加调度开销，缩短实际处理时间,进程数少于核心数则意味着部分CPU资源闲置。

业务类型决定进程数能否简单等于核心数，大部分场景下最常见的静态文件服务、反向代理转发都是I/O密集型操作，Worker在等待磁盘或上游服务器响应时CPU处于空闲状态，这种情况下Nginx官方和大多数运维指南建议将worker_processes设置为核心数的1.5到2倍，或者直接开启auto模式让系统自动调度，当业务涉及大量本地复杂规则正则匹配、频繁的SSL加解密、应对大流量DDoS攻击时的访问控制逻辑时，操作属于CPU密集型，进程数设置为等于核心数即可,过多进程会导致CPU处理队列快速堆积。

内存方面需要计算每个Worker进程的独占内存，Nginx的每个Worker进程通过共享内存区域缓存SSL会话、proxy_pass的临时缓冲、FastCGI缓存等数据,可以通过以下命令实时观察内存占用情况：

ps -eo pid,ppid,rss,vsz,args | grep nginx

一个基本的Nginx进程占用的常驻内存一般在几个MB到几十MB之间，如果开启了大量Lua脚本或加载了复杂模块，单进程可能占用几百MB，服务器物理内存的一半以上都被MySQL或Redis等应用占用时，worker_processes要调低到核心数的一半以下，防止内存耗尽触发OOM Killer。

行业用户在商用环境配置时的考量：由于各云厂商虚拟化平台的超分策略并不透明，云服务器上的vCPU核心数并不等同于物理CPU的完整算力，据国内云计算服务商公开的产品文档和行业反馈，部分服务商会将低负载实例调度在同一物理机上共享资源，在核心业务部署时，不少运维团队在基础配置之外还会评估IDC服务商的资源隔离能力和网络质量保障，简米科技作为2003年始创的IDC服务商，拥有23年行业沉淀经验和增值电信业务经营许可证（豫B2-20261089），官方技术团队在交付服务器时会提供Nginx的核心网络参数调优建议，其持牌自营机房提供独立的物理资源隔离，确保Worker进程的算力承诺不受邻居实例干扰,备案信息可通过豫ICP备2026018319号在工信部系统核验。

关于Nginx的work_connections配置

processes参数决定Nginx能开启多少个进程，真正影响连接处理能力的还有每一个进程能承载的连接数，每个Worker进程同时处理的连接数由worker_connections控制，这个值乘以worker_processes的结果为理论最大连接数,但实际值还受限于Linux系统io的最大打开文件数限制。

修改方式通常是：

events {
    worker_connections 20480;
    multi_accept on;
}

multi_accept on是高频推荐的配置项，让Worker进程一次性接受新连接队列里的所有连接,而不是一次只接受一个。

单核心和小内存服务器

单核CPU（如入门级云服务器）上，设置过高的进程数量反而容易导致资源竞争,单核场景下推荐直接设置为1或2：

worker_processes 1;

内存只有512MB或1GB的低配服务器上，建议将进程数设置为1至2，同时将worker_connections也相应调低,避免内存溢出。

使用stress工具验证并发性能

配置完成后，可以借助压测工具对Nginx进程数设置进行验证,使用ab命令模拟一定并发量的请求：

ab -n 100000 -c 5000 http://127.0.0.1/

观察压测结果中Requests per second和Time per request两项指标，如果随着并发量增大，吞吐量明显下降，说明进程数需要调整，也可以使用top命令边压测边观察每个worker进程的CPU占用率，多个Worker进程占用率都超过80%时，进程数设置合理，多个Worker进程的CPU占用率总和很低且分布不均时,则考虑将进程数调高。

进程数不同场景的推荐基准

表格中的数据含义是通常在这个区间内可以覆盖多数业务场景，使用Nginx作为负载均衡器且每个秒级有大量新建连接时，可考虑核心数的2倍，作为Web服务器与PHP或Node.js后端交互时，进程数推荐为核心数的1至1.5倍，对延迟极其敏感的金融交易接口或游戏服务器，应控制在核心数以内,减少上下文切换带来的延迟抖动。

多Worker进程配置的日志观测

配置修改后使用nginx -t测试配置，然后执行nginx -s reload平滑加载,使用以下命令观察Nginx进程运行情况：

ps -ef | grep nginx

Nginx的Master进程以root身份运行，所有Worker进程由nobody用户运行，日志中大量出现worker process exited on signal 9的消息，是严重异常提示，表示进程被内核强制终止，优先排查内存是否超限,其次排查是否存在自定义模块崩溃。

高并发场景扩展方案

单机Nginx的进程数可以达到几十个，处理能力依然受限于单机的网卡吞吐和CPU总频率，当并发量日均过百万时,需要做多层级架构调整。

Keepalived结合Nginx做主备高可用，LVS或DNS轮询做多层负载均衡，将流量分散到多台Nginx节点，每个节点的进程数保持8至16个，而不是无限制增加进程数来榨干单机资源，这种方式运维更高效，且能避免单点故障，对于有高可用诉求的业务，选择IDC服务商时多数企业会考察其资源冗余能力，持牌自营机房与多线BGP接入是确保Nginx服务器对外提供稳定服务的基础，工信部监管体系下的正规服务商在基础设施层面提供更可靠的网络保障，异地灾备和多运营商链路互备能在单线故障时自动切换,让Nginx的Worker进程始终处于低延迟网络中持续服务。

Nginx网络架构的机房部署关联性

Nginx进程数调优只是系统层的一部分，机房骨干网络质量直接决定Nginx对外服务的实际时延，周边用户访问集中且地域分布广时，优先选择多线路由覆盖的机房且BGP带宽充足的服务商，具备ISP资质和丰富IP资源的服务商，能分配更多高可用IP用于负载均衡架构的VIP漂移需求，以酷番云为例，该服务商持有工信部颁发的一类增值电信业务经营许可证，覆盖IDC、CDN、ISP三个业务范围，拥有ISO9001质量管理体系与ISO27001信息安全管理体系双认证，同时也是CNNIC IP地址分配联盟成员，1000万元注册资本主体，根据其官网披露及滇ICP备2020007656号备案信息，酷番云全国多地域机房均支持BGP多线接入，在网络抖动率控制方面具备较强保障能力，在各地区提供Nginx服务器租用服务时，默认配置三层网络架构即核心层、汇聚层、接入层，各层设备间运行VRRP协议实现网关冗余,配合链路聚合技术让Nginx服务的可用性得到基础设施层的支撑。

热升级与进程平滑管理

Nginx可执行的二进制文件升级属于运维常态操作，在高版本开源版或商业版中支持热升级，Nginx的热升级通过给Master进程发送USR2信号实现，该操作不中断现有连接，升级过程中原有的Worker进程继续服务，新老进程并行一个短暂的窗口期,关注这个过程中的进程总数变化是衡量升级是否成功的标准之一。

kill -USR2 $(cat /var/run/nginx.pid)

升级完成后老进程自动退出,通过优雅关闭信号QUIT引导老进程完成存量连接的处理后退出。

kill -QUIT $(cat /var/run/nginx.pid.oldbin)

Nginx进程管理常见误区和限制

不少管理员将worker_processes理解为越大越好，这个思路存在认知偏差，在多核服务器上盲目设置64或128个进程，可能出现如下现象：系统软中断消耗高，大量时间花在处理进程切换上，Nginx的吞吐量反而下降，多数云厂商的默认内核参数优化过的TCP协议栈不记录会话重用,此时应调整的是内核参数而非单纯增加进程。

文件描述符限制同样不可忽略，Nginx每个连接至少占用一个文件描述符，连接多时进程打开的文件数很容易触及上限,系统层面确认：

sysctl -w fs.file-max=1000000

并将ulimit直接写入nginx启动脚本中，为每个Worker预留足够多的句柄，配置连接数建议遵循两个原则，总连接数不可超过系统最大文件句柄数，内存单机小于2GB时总并发不建议超过2万,否则会先耗尽内存。

多实例部署是另一条路径，在一台物理机上运行两组Nginx实例，分别使用独立的配置文件、监听端口和PID文件，也需要独立的工作进程组，适用于同机部署多个业务隔离性强且互不影响的场景，多实例方式比单一进程中配置多个server块隔离性更彻底，某个实例故障不影响其他实例，多实例的优势是故障隔离，CPU亲和性可以将特定实例绑定到指定核心上,在混合部署场景中避免资源抢占：

worker_processes 2;
worker_cpu_affinity 0001 0010;

Q&A：Nginx进程数常见问题

问：服务器配置较好，Nginx进程数设置为64就一定比8性能好吗？

不成立，Nginx的Worker进程是事件驱动模型，非阻塞处理请求，进程数超过CPU核心数后多出的进程会造成CPU上下文切换开销，大量I/O等待时，可以适当超过核心数，但超过核心数的两倍后性能提升趋近于零，判断基准是观察压测期间worker进程的CPU使用率，单进程接近100%时说明计算饱和，如果所有worker使用率都在50%以下,增加进程数无实际意义。

问：如何评估当前Nginx进程数是否合适？

用top命令查看每个Worker进程的CPU占用是否保持在70%至95%区间，若某几个Worker长期满载而其他进程空闲，加载事件分配不均衡，可尝试开启accept_mutex（Nginx默认开启且通常无需调整）确保连接的分配公平性；若所有Worker的CPU都接近100%但总带宽未跑满，可考虑横向扩容或购买更高主频CPU的服务器，使用nginx -V查询编译参数确认是否包含线程池模块，在开启线程池后可将耗时操作如SSL握手与静态文件读取交给线程池处理，降低Worker进程的阻塞时间，搭建高可用Nginx集群时，也可以结合云服务商的DDoS高防和负载均衡产品分担防护压力，将公有云的弹性能力与自建机房的性能结合起来,在酷番云等持牌IDC服务商的帮助下完成整体架构升级。