修改 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-19 11:46:45

    @EnableConfigurationProperties注解详解,源码

    用springboot开发的过程中,我们会用到@ConfigurationProperties注解,主要是用来把properties或者yml配置文件转化为bean来使用的,而@EnableConfigurationProperties注解的作用是@ConfigurationProperties注解生效。 如果只配置@ConfigurationProperties注解,在IOC容器中是获取不到properties配置文件转化的bean的,当然在@ConfigurationProperties加入注解的类上加@Component也可以使交于springboot管理。

  • 2019-09-19 14:10:03

    Android UI布局优化之ViewStub介绍

    ViewStub的inflate只能被调用一次,第二次调用会抛出异常,setVisibility可以被调用多次,但不建议这么做(文章中说原因)

  • 2019-09-19 14:21:47

    Dubbo和spring cloud微服务框架区别和介绍

    关于 Dubbo 和 Spring Cloud 的相关概念和对比,上面已经叙述的很清楚了,我个人比较倾向于 Spring Cloud,原因就是真正的微服务框架、提供整套的组件支持、使用简单方便、强大的社区支持等等,另外,因为考虑到 .NET/.NET Core 的兼容处理,RPC 并不能很好的实现跨语言(需要借助跨语言库,比如 gRPC、Thrift,但因为 Dubbo 本身就是“gRPC”,在 Dubbo 之上再包一层 gRPC,有点重复封装了),而 HTTP REST 本身就是支持跨语言实现,所以,Spring Cloud 这一点还是非常好的(Dubbox 也支持,但性能相比要差一些)。

  • 2019-09-22 07:12:04

    git Please move or remove them before you can merge

    这是因为本地有修改,与云端别人提交的修改冲突,又没有merge. 如果确定使用云端的代码,最方便的解决方法是删除本地修改,可以使用以下命令: git clean -d -fx

  • 2019-09-22 07:36:52

    ALIN10146-自查方案

    报错原因 1.请求appid应用未上线或者是应用类型是第三方应用 2.签约权限问题 3.签名类型使用错误 4.请求参数问题 5.秘钥匹配问题 6.应用类型问题

  • 2019-09-22 07:37:44

    ALIN10146,ALI38173支付宝APP支付集成时出现的问题

    最近在做支付宝APP的集成,遇到了一堆问题。百度不到,ALI64还好点,ALI38173基本上就没了。我也是测试了很久才解决的。ALI64的解决方案是因为要对私钥有问题。ALI38173是签名有问题。签名的解决方...

  • 2019-09-22 22:32:20

    Spring Shiro 使用默认的Session会话管理

    项目中用到了shiro session会话管理机制,今天来总结一下,以下都是在spring boot框架实现。 shiro的session管理机制很完善,也是独立于j2ee容器且不依赖的,所以我们完全可以使用shiro提供给我们的session会话管理来实现我们的业务逻辑,默认提供的sessionDAO是memorySessionDAO,这里也主要讲它的配置和原理。 首先来看下如何在spring boot下配置默认的session会话管理: ShiroConfig类: