6.18前夜系统宕机了怎么办?(全程实战,建议收藏)

Posted 冰 河

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了6.18前夜系统宕机了怎么办?(全程实战,建议收藏)相关的知识,希望对你有一定的参考价值。

大家好,我是冰河~~

最近,在服务器上搭建了一套压测环境,不为别的,就为压测下nginx的性能,到底有没有传说中的那么牛逼!具体环境为:11台虚拟机,全部安装CentOS 6.8 64位操作系统,1台安装部署Nginx,其他10台作为客户端同时以压满CPU的线程向Nginx发送请求,对Nginx进行压测。没想到,出现问题了!!

小伙伴们如果觉得文章不错,点赞、收藏、评论,分享走一起呀,记得给冰河来个一键三连~~

好了,我们开始今天的正文。

Nginx报错

Nginx服务器访问量非常高,在Nginx的错误日志中不停的输出如下错误信息。

2021-06-17 02:53:49 [alert] 13576#0: accept() failed (24: Too many open files)
2021-06-17 02:53:49 [alert] 13576#0: accept() failed (24: Too many open files)
2021-06-17 02:53:49 [alert] 13576#0: accept() failed (24: Too many open files)
2021-06-17 02:53:49 [alert] 13576#0: accept() failed (24: Too many open files)
2021-06-17 02:53:49 [alert] 13576#0: accept() failed (24: Too many open files)
2021-06-17 02:53:49 [alert] 13576#0: accept() failed (24: Too many open files)
2021-06-17 02:53:49 [alert] 13576#0: accept() failed (24: Too many open files)
2021-06-17 02:53:49 [alert] 13576#0: accept() failed (24: Too many open files)
2021-06-17 02:53:49 [alert] 13576#0: accept() failed (24: Too many open files)
2021-06-17 02:53:49 [alert] 13576#0: accept() failed (24: Too many open files)

根据错误日志的输出信息,我们可以看出:是打开的文件句柄数太多了,导致Nginx报错了!那我们该如何解决这个问题呢?

问题分析

既然我们能够从Nginx的错误日志中基本能够确定导致问题的原因,那这到底是不是Nginx本身的问题呢?答案为:是,也不全是!

为啥呢?原因很简单:Nginx无法打开那么多的文件句柄,一方面是因为我没有配置Nginx能够打开的最大文件数;另一方面是因为CentOS 6.8操作系统本身对打开的最大文件句柄数有限制,我同样没有配置操作系统的最大文件句柄数。所以说,不全是Nginx的锅!在某种意义上说,我错怪Nginx了!

在CentOS 6.8服务器中,我们可以在命令行输入如下命令来查看服务器默认配置的最大文件句柄数。

[root@binghe150 ~]# ulimit -n
1024

可以看到,在CentOS 6.8服务器中,默认的最大文件句柄数为1024。

此时,当Nginx的连接数超过1024时,Nginx的错误日志中就会输出如下错误信息。

[alert] 13576#0: accept() failed (24: Too many open files)

解决问题

那我们该如何解决这个问题呢?其实,也很简单,继续往下看!

使用如下命令可以把打开文件句柄数设置的足够大。

ulimit -n 655350

同时修改nginx.conf , 添加如下配置项。

worker_rlimit_nofile 655350; 

注意:上述配置需要与error_log同级别。

这样就可以解决Nginx连接过多的问题,Nginx就可以支持高并发(这里需要配置Nginx)。

另外, ulimit -n还会影响到mysql的并发连接数。把它提高,也可以提高MySQL的并发。

注意: 用 ulimit -n 655350 修改只对当前的shell有效,退出后失效。

永久解决问题

若要令修改ulimits的数值永久生效,则必须修改配置文件,可以给ulimit修改命令放入/etc/profile里面,这个方法实在是不方便。

还有一个方法是修改/etc/security/limits.conf配置文件,如下所示。

vim /etc/security/limits.conf

在文件最后添加如下配置项。

* soft nofile 655360
* hard nofile 655360

保存并退出vim编辑器。

其中:星号代表全局, soft为软件,hard为硬件,nofile为这里指可打开的文件句柄数。

最后,需要注意的是:要使 limits.conf 文件配置生效,必须要确保 pam_limits.so 文件被加入到启动文件中。查看 /etc/pam.d/login 文件中是否存在如下配置。

session required /lib64/security/pam_limits.so

不存在,则需要添加上述配置项。

写在最后

如果你想进大厂,想升职加薪,或者对自己现有的工作比较迷茫,都可以私信我交流,希望我的一些经历能够帮助到大家~~

推荐阅读:

好了,今天就到这儿吧,小伙伴们点赞、收藏、评论,一键三连走起呀,我是冰河,我们下期见~~

以上是关于6.18前夜系统宕机了怎么办?(全程实战,建议收藏)的主要内容,如果未能解决你的问题,请参考以下文章

我入侵了隔壁妹子的Wifi,发现。。。(全程实战干货,建议收藏)

牛!一次实战批量SRC和CNVD的奇技淫巧(全程干货,建议收藏)

面试官让我现场手写MyBatis框架,我10分钟就搞定了!!(全程实战,建议收藏)

硬核!4.5万字手把手教你搭建MySQL海量数据存储架构!!(全程实战,建议收藏)

刚来公司一周,搭建了一套持续集成交付环境,研发效率直接提升20倍,CTO再次给我涨薪!!(全程实战,建议收藏)

MySQL一主多从的环境下,如果主宕机了怎么办?如何把损失降到最小?