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)下载
1 | [] |
-n 请求数
-c 并发数
-r 不在接手错误是退出
ab命令并发最大在2w,可以提升,我这里没有做处理2w足够复现了
当使用ab命令请求是如果终端报错,临时将宿主机ulimit调大(ulimit -n 65535)
是因为宿主机每个进程可以同时打开的最大文件句柄数默认在1024,压测是比实际请求更大量的请求,ab命令严格来说不是很严谨
1 | [] |
设置工作进程连接数1024 (压测并发都为2w)
1 | events { |
日志大量报错
大量连接状态为TIME_WAIT
以上现象我大概理解为,1连接数过多、2打开句柄文件过多导致问题出现
设置工作进程连接数124
1 | events { |
没有错误日志,请求应该是在排队中,这个时候我查看access日志时发现请求日志是一批一批进来的,我这里可能与实际的业务请求有偏差,我也就是请求一个index.html静态页面,实际的业务应该还会有更多的动作
大量连接状态为FIN_WAIT_2
实际上FIN_WAIT_2状态下的SOCKET,表示半连接,也即有一方要求close连接,但另外还告诉对方,我暂时还有点数据需要传送给你,稍后再关闭连接
设置工作线程连接数和worker_rlimit_nofile 65535
1 | worker_rlimit_nofile 65535; |
worker_rlimit_nofile 65534; 这个值默认根据系统ulimnt,此设置为将工作进程的最大文件打开数限制,覆盖系统默认1024的参数,但不会改变master进程的文件打开数,你可以设置此值后查看master进程和工作进程的参数不一样(重启生效)
1 | [] |
请求正常,无报错
从16:37一直到16:42在没有错误日志,而且access日志没有出现分批的情况
永久修改系统ulimit参数(可选)
Linux系统中ulimit-n的配置文件通常为/etc/security/limits.conf。我们需要在该配置文件中添加以下内容
1 | * soft nofile 65536 |
以上简单的方式算是一个粗略的测试,从而简单的看到什么情况出现Too many open files的问题所在,也是我自己的个人理解,以简单记录
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 liujxu!
















