解决Nginx出现“Too many open files”的问题

Posted 2023-03-05 OkidoGreen

最近发现https://imgurl.org/ 自建CDN节点偶尔出现无法打开的情况，查看服务器负载不高，nginx连接数大概在1024后就无法处理，按理说nginx处理1024左右的并发还是绰绰有余的，但就是出现无法打开的情况，查看nginx错误日志，出现大量的“Too many open files”错误，大致意思就是说nginx无法打开更多的文件，看来问题并不在并发数上面。

出现这个错误可能是由于系统的ulimit限制和nginx自身的配置有关系，先来了解下概念。

什么是ulimit?

ulimit命令用来限制系统用户对shell资源的访问。如果不懂什么意思，下面一段内容可以帮助你理解：

假设有这样一种情况，当一台 Linux 主机上同时登陆了 10 个人，在系统资源无限制的情况下，这 10 个用户同时打开了 500 个文档，而假设每个文档的大小有 10M，这时系统的内存资源就会受到巨大的挑战。

ulimit 用于限制 shell 启动进程所占用的资源，支持以下各种类型的限制：所创建的内核文件的大小、进程数据块的大小、Shell 进程创建文件的大小、内存锁住的大小、常驻内存集的大小、打开文件描述符的数量、分配堆栈的最大大小、CPU 时间、单个用户的最大线程数、Shell 进程所能使用的最大虚拟内存。同时，它支持硬资源和软资源的限制。

简单来说，ulimit描述符可以对用户打开的文件数量进行限制（不止限制打开文件数量），让单个用户不至于打开较多的文件，导致系统奔溃或者资源不足的情况。

查看ulimit

既然知道了ulimit是做什么的，首先要先知道系统底层限制到底是多少，ulimit的参数如下：

-a：显示目前资源限制的设定；

-c <core文件上限>：设定core文件的最大值，单位为区块；

-d <数据节区大小>：程序数据节区的最大值，单位为KB；

-f <文件大小>：shell所能建立的最大文件，单位为区块；

-H：设定资源的硬性限制，也就是管理员所设下的限制；

-m <内存大小>：指定可使用内存的上限，单位为KB；

-n <文件数目>：指定同一时间最多可开启的文件数；

-p <缓冲区大小>：指定管道缓冲区的大小，单位512字节；

-s <堆叠大小>：指定堆叠的上限，单位为KB；

-S：设定资源的弹性限制；

-t <CPU时间>：指定CPU使用时间的上限，单位为秒；

-u <程序数目>：用户最多可开启的程序数目；

-v <虚拟内存大小>：指定可使用的虚拟内存上限，单位为KB。

由于上述nginx错误是无法打开过多的文件，那么我们直接使用ulimit -n查看同一时间最多可开启的文件数。​​​​​​​

[root@bwh-cdn conf]# ulimit -n

1024

从上述命令可以看出限制的1024个文件，这就导致nginx尝试打开更多的文件（超出1024个）的时候出现错误“Too many open files”

解决办法

修改ulimit限制

直接执行命令ulimit -n 65535修改打开文件数，65535指的是需要同一时间最多打开多少个文件，请根据自身情况适当修改。

ulimit命令修改只对当前的shell有效，退出后失效，如果需要永久生效，需要修改/etc/security/limits.conf这个文件，在底部加入下面的配置：

* soft nproc 65535

* hard nproc 65535

* soft nofile 65535

* hard nofile 65535

*：代表全局

soft：代表软件

hard：代表硬件

nproc：是代表最大进程数

nofile：是代表最大文件打开数

修改完毕后，再次执行命令：ulimit -n可以看到设置已经生效：​​​​​​​

[root@rakcdn conf]# ulimit -n

65535

修改nginx打开文件限制

修改nginx.conf加入一行，并重载nginx配置：nginx -s reload

worker_processes  1;
worker_rlimit_nofile 65535;
events 
   worker_connections  65535;

worker_rlimit_nofile这个参数的含义是：“为nginx工作进程改变打开最多文件描述符数目的限制。用来在不重启主进程的情况下增加限制。”

总结

上述操作修改了2个地方，一个是ulimit限制，一个是nginx的worker_rlimit_nofile限制。修改后nginx读取更多的文件轻轻松松