nginx复现问题accept4() failed (24: Too many open files)

nginx在近两天连接数上去的时候业务有影响,错误日志频繁出现accept4() failed (24: Too many open files)报错信息,后续业务低峰自动恢复,以3种方式复现测试会报错的原因记录如下

请求模拟:使用nginx反向代理一个java后端
请求工具:使用ab命令(yum install httpd-tools -y)下载

[root@ceshi-132 ~]# ab -r -c 20000 -n 2000000 http://10.1.133.92/osbinfo > osb.log

-n 请求数
-c 并发数
-r 不在接手错误是退出
ab命令并发最大在2w,可以提升,我这里没有做处理2w足够复现了

当使用ab命令请求是如果终端报错,临时将宿主机ulimit调大(ulimit -n 65535)
是因为宿主机每个进程可以同时打开的最大文件句柄数默认在1024,压测是比实际请求更大量的请求,ab命令严格来说不是很严谨

[root@ceshi-132 ~]# ab -r -c 20000 -n 20000000 http://10.1.133.92/osbinfo > osb.log
socket: Too many open files (24)

1. 设置工作进程连接数1024 (压测并发都为2w)

events {
    worker_connections  1024;
}
1.1 日志大量报错

在这里插入图片描述

1.2 大量连接状态为TIME_WAIT

在这里插入图片描述
以上现象我大概理解为,1连接数过多、2打开句柄文件过多导致问题出现

2. 设置工作进程连接数124

events {
    worker_connections  124;
}
2.1 没有错误日志,请求应该是在排队中,这个时候我查看access日志时发现请求日志是一批一批进来的,我这里可能与实际的业务请求有偏差,我也就是请求一个index.html静态页面,实际的业务应该还会有更多的动作
2.2 大量连接状态为FIN_WAIT_2

实际上FIN_WAIT_2状态下的SOCKET,表示半连接,也即有一方要求close连接,但另外还告诉对方,我暂时还有点数据需要传送给你,稍后再关闭连接
在这里插入图片描述

3. 设置工作线程连接数和worker_rlimit_nofile 65535

worker_rlimit_nofile 65535;

events {
    worker_connections  1024;
}
3.1 worker_rlimit_nofile 65534; 这个值默认根据系统ulimnt,此设置为将工作进程的最大文件打开数限制,覆盖系统默认1024的参数,但不会改变master进程的文件打开数,你可以设置此值后查看master进程和工作进程的参数不一样(重启生效)
[root@ceshi-128 logs]# ps -aux |grep nginx 
root      46936  0.0  0.0  46216  1212 ?        Ss   10:58   0:00 nginx: master process ../sbin/nginx
nobody    46937 64.3  0.0  46712  2500 ?        S    10:58   5:12 nginx: worker process
root      46998  0.0  0.0 112812   976 pts/0    S+   11:06   0:00 grep --color=auto nginx
[root@ceshi-128 logs]# cat /proc/46936/limits |grep "open files"

在这里插入图片描述

3.2 请求正常,无报错

从16:37一直到16:42在没有错误日志,而且access日志没有出现分批的情况
在这里插入图片描述

3.3 永久修改系统ulimit参数(可选)

Linux系统中ulimit-n的配置文件通常为/etc/security/limits.conf。我们需要在该配置文件中添加以下内容

*     soft    nofile   65536 	#软件
*     hard    nofile   65536 	#硬件

以上简单的方式算是一个粗略的测试,从而简单的看到什么情况出现Too many open files的问题所在,也是我自己的个人理解,以简单记录

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 当Nginx报错“accept4() failed (24: too many open files)”时,意味着系统打开的文件描述符数量已达到或超过了系统的限制。 文件描述符是操作系统为了管理打开的文件而分配给进程的整数。当一个进程打开文件时,操作系统会为其分配一个文件描述符。这些文件可以是网络连接、文件等。 当Nginx处理请求时,它会用到大量的文件描述符来处理客户端的连接。因此,如果系统的文件描述符限制太低,就会导致Nginx无法创建足够数量的文件描述符来处理客户端连接,从而报错。 解决这个问题的方法是调整系统的文件描述符限制。可以通过以下步骤来增加文件描述符的数量: 1. 打开终端并以管理员身份登录系统。 2. 编辑`/etc/sysctl.conf`文件,使用以下命令打开文件: `sudo nano /etc/sysctl.conf` 3. 在文件的末尾添加以下行: ``` fs.file-max = 65536 ``` 4. 保存并关闭文件。 5. 编辑`/etc/security/limits.conf`文件,使用以下命令打开文件: `sudo nano /etc/security/limits.conf` 6. 在文件的末尾添加以下行: ``` * soft nofile 65536 * hard nofile 65536 ``` 7. 保存并关闭文件。 8. 重启系统,以使更改生效: `sudo reboot` 重启后,系统将具有更高的文件描述符限制,Nginx就能够处理更多的连接而不再报错“accept4() failed (24: too many open files)”。 ### 回答2: 在Nginx的错误日志中,出现"accept4() failed (24: too many open files)"的报错,这意味着系统中打开的文件数已经达到了操作系统允许的最大限制。在Linux系统中,默认情况下,操作系统为每个进程设置了一定的文件打开限制。 引起这个问题的原因可能是Nginx进程打开的文件数超过了操作系统的限制。当Nginx处理许多并发请求时,会为每个连接打开一个文件描述符。如果并发连接数过高或系统文件描述符的限制较低,就可能导致这个问题的发生。 为了解决这个问题,可以采取以下措施: 1. 增加操作系统文件描述符限制:可以通过修改系统的ulimit设置来增加每个进程允许打开的文件数。可以编辑/etc/security/limits.conf文件,并添加以下行: ``` * hard nofile 65535 * soft nofile 65535 ``` 这将将每个进程打开的文件数限制增加到65535。 2. 优化Nginx配置:可以通过调整Nginx的worker_processes和worker_connections参数来避免打开过多的文件。worker_processes应该设置为适当的值,以便充分利用系统的处理能力。worker_connections则应根据系统资源和预期的并发连接数进行调整,以避免超出操作系统的限制。 3. 优化系统资源:可以评估系统的资源使用情况,例如CPU、内存和磁盘IO等。如果系统资源不足,可能需要升级硬件或优化其他应用程序以释放资源。 总之,解决Nginx报错"accept4() failed (24: too many open files)"的问题,需要同时优化系统资源和Nginx配置,确保操作系统的文件描述符限制不会成为瓶颈,并合理设置Nginx的并发连接数。 ### 回答3: 当Nginx报错“accept4() failed (24: too many open files)”时,意味着服务器的打开文件数已经超过了系统的限制。 这个错误通常是由于服务器同时处理的连接数太多,导致Nginx无法打开更多的文件而引发的。操作系统对每个进程都设置了最大打开文件数的限制,这个限制可以针对整个系统或者单个用户设置。 要解决这个问题,可以采取以下措施: 1. 增加系统的最大打开文件数限制:可以通过修改操作系统的配置文件来增加最大打开文件数限制。具体的修改方式与操作系统有关,需要参考官方文档或相关论坛进行配置。 2. 优化Nginx配置:可以通过优化Nginx的配置来减少连接数,从而降低打开文件数。比如调整连接超时时间、增加反向代理缓存等。 3. 优化服务器资源:可以通过增加服务器内存、升级硬件等方式来提升服务器的性能和处理能力,从而减少连接数,降低打开文件数。 4. 检查程序中的资源泄漏:有时候,程序中存在资源泄漏会导致打开文件数不断增加。可以通过检查程序的代码,查找并修复可能的资源泄漏问题。 需要注意的是,以上措施必须在对服务器有足够了解的情况下进行操作,避免产生其他不可预料的问题。另外,建议及时监测服务器的打开文件数以及其他性能指标,以便及时发现和解决类似问题
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值