修改 Nginx 进程最大可打开文件数(worker_processes和worker_connections)

2019-08-13 20:06:42

参考地址 修改 Nginx 进程最大可打开文件数(worker_processes和worker_connections)

worker_processes:操作系统启动多少个工作进程运行Nginx。注意是工作进程,不是有多少个nginx工程。在Nginx运行的时候,会启动两种进程,一种是主进程master process;一种是工作进程worker process。例如我在配置文件中将worker_processes设置为4,启动Nginx后,使用进程查看命令观察名字叫做nginx的进程信息,我会看到如下结果:


[root@localhost nginx]#  ps -elf | grep nginx

4 S root       2203   2031  0  80   0 - 46881 wait   22:18 pts/0    00:00:00 su nginx

4 S nginx      2204   2203  0  80   0 - 28877 wait   22:18 pts/0    00:00:00 bash

5 S root       2252      1  0  80   0 - 11390 sigsus 22:20 ?        00:00:00 nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf

5 S nobody     2291   2252  0  80   0 - 11498 ep_pol 22:23 ?        00:00:00 nginx: worker process

5 S nobody     2292   2252  0  80   0 - 11498 ep_pol 22:23 ?        00:00:00 nginx: worker process

5 S nobody     2293   2252  0  80   0 - 11498 ep_pol 22:23 ?        00:00:00 nginx: worker process

5 S nobody     2294   2252  0  80   0 - 11498 ep_pol 22:23 ?        00:00:00 nginx: worker process

0 R root       2312   2299  0  80   0 - 28166 -      22:24 pts/0    00:00:00 grep --color=auto nginx

1

2

3

4

5

6

7

8

9

图中可以看到1个nginx主进程,master process;还有四个工作进程,worker process。主进程负责监控端口,协调工作进程的工作状态,分配工作任务,工作进程负责进行任务处理。一般这个参数要和操作系统的CPU内核数成倍数。


worker_connections:这个属性是指单个工作进程可以允许同时建立外部连接的数量。无论这个连接是外部主动建立的,还是内部建立的。这里需要注意的是,一个工作进程建立一个连接后,进程将打开一个文件副本。所以这个数量还受操作系统设定的,进程最大可打开的文件数有关。


设置Nginx进程最大可打开文件数

1、更改操作系统级别的“进程最大可打开文件数”的设置

Linux问题—设置“进程最大可打开的文件数”永久有效的方式。


2、更改Nginx软件级别的“进程最大可打开文件数”的设置

刚才更改的只是操作系统级别的“进程最大可打开文件”的限制,作为Nginx来说,我们还要对这个软件进行更改。打开nginx.conf主配置文件。您需要配合worker_rlimit_nofile属性。如下:


user root root; 

worker_processes 4; 

worker_rlimit_nofile 65535;


#error_log logs/error.log; 

#error_log logs/error.log notice; 

#error_log logs/error.log info;


#pid logs/nginx.pid; 

events { 

        use epoll; 

        worker_connections 65535; 

}


这里只粘贴了部分代码,其他的配置代码和主题无关,也就不需要粘贴了。请注意代码行中加粗的两个配置项,请一定两个属性全部配置。配置完成后,请通过nginx -s reload命令重新启动Nginx。


3、验证Nginx的“进程最大可打开文件数”是否起作用

那么我们如何来验证配置是否起作用了呢?在linux系统中,所有的进程都会有一个临时的核心配置文件描述,存放路径在 /pro/进程号/limit。


首先我们来看一下,没有进行参数优化前的进程配置信息:


[root@localhost nginx]#  ps -elf | grep nginx

4 S root       2203   2031  0  80   0 - 46881 wait   22:18 pts/0    00:00:00 su nginx

4 S nginx      2204   2203  0  80   0 - 28877 wait   22:18 pts/0    00:00:00 bash

5 S root       2252      1  0  80   0 - 11390 sigsus 22:20 ?        00:00:00 nginx: master process /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf

5 S nobody     2291   2252  0  80   0 - 11498 ep_pol 22:23 ?        00:00:00 nginx: worker process

5 S nobody     2292   2252  0  80   0 - 11498 ep_pol 22:23 ?        00:00:00 nginx: worker process

5 S nobody     2293   2252  0  80   0 - 11498 ep_pol 22:23 ?        00:00:00 nginx: worker process

5 S nobody     2294   2252  0  80   0 - 11498 ep_pol 22:23 ?        00:00:00 nginx: worker process

0 R root       2318   2299  0  80   0 - 28166 -      22:42 pts/0    00:00:00 grep --color=auto nginx

1

2

3

4

5

6

7

8

9

可以看到,nginx工作进程的进程号是:2291 2292 2293 2294。我们选择一个进程,查看其核心配置信息:


[root@localhost nginx]# cat /proc/2291/limits

Limit                     Soft Limit           Hard Limit           Units

Max cpu time              unlimited            unlimited            seconds

Max file size             unlimited            unlimited            bytes

Max data size             unlimited            unlimited            bytes

Max stack size            8388608              unlimited            bytes

Max core file size        0                    unlimited            bytes

Max resident set          unlimited            unlimited            bytes

Max processes             3829                 3829                 processes

Max open files            1024                 4096                 files

Max locked memory         65536                65536                bytes

Max address space         unlimited            unlimited            bytes

Max file locks            unlimited            unlimited            locks

Max pending signals       3829                 3829                 signals

Max msgqueue size         819200               819200               bytes

Max nice priority         0                    0

Max realtime priority     0                    0

Max realtime timeout      unlimited            unlimited            us

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

请注意其中的Max open files ,分别是1024和4096。那么更改配置信息,并重启Nginx后,配置信息就是下图所示了:


[root@localhost conf]# cat /proc/2351/limits

Limit                     Soft Limit           Hard Limit           Units

Max cpu time              unlimited            unlimited            seconds

Max file size             unlimited            unlimited            bytes

Max data size             unlimited            unlimited            bytes

Max stack size            8388608              unlimited            bytes

Max core file size        0                    unlimited            bytes

Max resident set          unlimited            unlimited            bytes

Max processes             3829                 3829                 processes

Max open files            65535                65535                files

Max locked memory         65536                65536                bytes

Max address space         unlimited            unlimited            bytes

Max file locks            unlimited            unlimited            locks

Max pending signals       3829                 3829                 signals

Max msgqueue size         819200               819200               bytes

Max nice priority         0                    0

Max realtime priority     0                    0

Max realtime timeout      unlimited            unlimited            us



  • 2019-09-16 22:56:52

    java.lang.NoSuchMethodError:SpringJAR包版本冲突错误解决方法

    查询了相关资料,大部分都说引起的原因是JAR包错误或JAR包冲突,查看了配置文件,并没有发现错误之处,因为用的是maven工程,这让我想到了maven的JAR引用的传递性,应该是引用的JAR包中传递引用了相同的包,没有排除。通过mvn dependency:tree 命令查看当前工程引用的依赖JAR树

  • 2019-09-17 17:19:42

    strapi 先进的 headless cms

    为什么叫cms而不是框架,主要是因为他提供了一个程序员操作面板,看起来像是一个综合的后台管理,很容易误解具体项目的后台管理,他更像是一个数据库管理面板顺便完成api的自动开发操作。

  • 2019-09-17 17:20:59

    Headless CMS 的介绍

    在本文中,我们将了解Headless CMS,我们将了解它的优点以及何时使用方便。此外,我们将列举实际的主要限制。为了更好地理解HCMS如何在幕后工作,我将解释如何设计和构建RawCMS,一个带有Oauth2的Aspnet.Core Headless CMS,扩展插件系统,业务逻辑支持。该解决方案可在GitHub上获得,并作为演示版在docker hub上发布。

  • 2019-09-17 17:21:58

    Headless CMS 详细介绍

    什么是 Headless CMS? 为什么 Headless CMS 带有真正的革命性?因为它严格的将内容和格式分离,使我们回归到内容管理的本源。这种变化必然会带来一些不确定性。因此,在开始您的第一个 CMS 项目之前,了解 Headless CMS 概念至关重要。因为它和传统的 CMS 有着本质的区别。