Nginx 高级篇（九）单机并发 1 万 10 万次请求解决和优化方案

huxiaobai_001 的个人博客 / 781 / 6 / 创建于 4年前 / 更新于 4年前

前提！必须声明前提！
前提：我这里只是调通nginx支撑单机1万并发100000次请求甚至更高不带后边的php-fpm mysql memcache的tcp链接玩哈！光调整nginx并发1万10万次请求就够费劲的后边带上php-fpm或者mysql memcache还得要进行优化哪那么简单草！
Nginx 高级篇（八）ab 压力测试即 nginx 的性能统计模块
这篇文章的最后我们提到ab测试并发10000 访问量20000的时候界面就直接卡死了！
为啥就卡死了呢？总得有原因吧？有问题找原因！
两个方向：
http请求一个socket链接的建立另一个就是文件的读取解释或者编译

socket的建立是系统级别的所以我们首先去查系统

查看linux内核日志：
dmesg|tail
如图所示报错了吧：

这错是啥意思呢？
代理或者服务器设备都有端口限制，如果使用 TCP 连接，连接数量达到端口限制，在这种情况下，将不能创建新的连接。就这意思，说白了就是你的tcp链接太多啦！

现在我们再去看nginx的错误日志

more /usr/local/nginx/logs/error.log
看看吧少年：

Too many open files：
too many open files是Linux系统中常见的错误，从字面意思上看就是说程序打开的文件数过多，不过这里的files不单是文件的意思，也包括打开的通讯链接(比如socket)，正在监听的端口等等，所以有时候也可以叫做句柄(handle)，这个错误通常也可以叫做句柄数超出系统限制。
引起的原因就是进程在某个时刻打开了超过系统限制的文件数量以及通讯链接数，通过命令
ulimit -n
```shell
more /usr/local/nginx/logs/error.log
引起的原因就是进程在某个时刻打开了超过系统限制的文件数量以及通讯链接数，通过命令
ulimit -n
可以查看当前系统设置的最大句柄数是多少!可以查看当前系统设置的最大句柄数是多少!

也就是说造成失败的原因有两个大方向
一：nginx
二：系统层面
咋办啊？只能优化了，优化系统层面的和优化Nginx各项配置，这他妈都运维的活了，我一搞研发的我发现我研究的有点跑题了！写吧！往下看！

系统层面优化和Nginx的配置优化使其满足一万并发的要求

先画个图定好整体的优化方向别瞎几把优化优化不好系统或者Nginx就摊了!

前沿：
高并发解决的前提思路是socket(tcp)连接数要顶住还有就是处理程序的时候文件打开的数量要顶住！这两个有一个顶不住就不用谈什么高并发处理！这是前提条件！

socket(http请求)层面：
1.http链接快速关闭 keep_alivetime:0
先来了解一下这个http的keep-alivetime是干哈滴
你打开很多网站请求头信息会发现都有它
在http早期，每个http请求都要求打开一个tpc socket连接，并且使用一次之后就断开这个tcp连接。
使用keep-alive可以改善这种状态，即在一次TCP连接中可以持续发送多份数据而不会断开连接。通过使用keep-alive机制，可以减少tcp连接建立次数，也意味着可以减少TIME_WAIT状态连接，以此提高性能和提高httpd服务器的吞吐率(更少的tcp连接意味着更少的系统内核调用,socket的accept()和close()调用)。
但是，keep-alive并不是免费的午餐,长时间的tcp连接容易导致系统资源无效占用。配置不当的keep-alive，有时比重复利用连接带来的损失还更大。所以，正确地设置keep-alive timeout时间非常重要。
keepalvie timeout
Httpd守护进程，一般都提供了keep-alive timeout时间设置参数。比如nginx的keepalive_timeout，和Apache的KeepAliveTimeout。这个keepalive_timout时间值意味着：一个http产生的tcp连接在传送完最后一个响应后，还需要hold住keepalive_timeout秒后，才开始关闭这个连接。
当httpd守护进程发送完一个响应后，理应马上主动关闭相应的tcp连接，设置 keepalive_timeout后，httpd守护进程会想说：”再等等吧，看看浏览器还有没有请求过来”，这一等，便是keepalive_timeout时间。如果守护进程在这个等待的时间里，一直没有收到浏览发过来http请求，则关闭这个http连接。
重点：长时间的tcp连接容易导致系统资源无效占用在如此高并发的前提下如果还让一个连接保持65s的时间简直是大大的浪费浪费浪费，这么多人在抢资源你还站着厕所不拉屎！所以，第一步就是来解决它：
找到Nginx的配置文件（改成0即可表示没有保持时间）：

2.子进程允许打开的链接（worker_connections）

先来了解一下Nginx里面的worker_connections是干啥滴？
原来安装好nginx之后，默认最大的并发数为1024，如果你的网站访问量过大，已经远远超过1024这个并发数，那你就要修改worker_connecions这个值，这个值越大，并发数也有就大。当然，你一定要按照你自己的实际情况而定，也不能设置太大，不能让你的CPU跑满100%；
worker_connections进程连接数量要小于等于系统的最大打开文件数

3.设置系统最大打开文件数：
在2当中不都讲了吗 worker_connections进程连接数量要小于等于系统的最大打开文件数我们在Nginx当中已经设置了worker_connecions 10240
给系统最大打开文件数来个2万
执行命令：
ulimit -n 20000
4.设置系统的最大链接数：
先看看系统最大链接数是干哈滴？
/proc/sys/net/core/somaxconn这个参数 linux中内核的一个不错的参数somaxconn
对于一个TCP连接，Server与Client需要通过三次握手来建立网络连接.当三次握手成功后,
我们可以看到端口的状态由LISTEN转变为ESTABLISHED,接着这条链路上就可以开始传送数据了.
每一个处于监听(Listen)状态的端口,都有自己的监听队列.监听队列的长度,与如下两方面有关:
somaxconn参数定义了系统中每一个端口最大的监听队列的长度,这是个全局的参数,默认值为128,对于一个经常处理新连接的高负载 web服务环境来说，默认的 128 太小了！高并发情况下所以要调大！
执行命令：
echo 50000 > /proc/sys/net/core/somaxconn #50000有点猛哈 你根据自己情况来定
5.加快tcp连接的回收（recycle）:
采用Nginx反向代理服务后，操作系统会产生较多TIME_WAIT的TCP（Transmission Control Protocol）连接，操作系统默认TIME_WAIT的TCP连接回收时间是2分钟，这样会使回收TCP过慢导致系统吞吐量下降，甚至出现502访问失败问题！如此大并发的场景下必须要加快tcp链接的回收！
执行命令：
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle #默认为0 表示不快速回收120s后回收
6.空的tcp是否允许回收利用（reuse）
先来了解一下tcp_tw_reuse?
tcp_tw_reuse 设置允许在TIME_WAIT 状态下重复使用一对套接字，由内核确保不会有类似于重复序列号的问题。由于两端都使用了时间戳，所以能够避免序列号重复。也可以基于某些关闭标识如FIN（表示不会有新的流量），来重复使用套接字。
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse #默认为0 表示允许回收利用
7.洪水攻击（不做洪水攻击抵御）
什么是洪水攻击？
洪水攻击（FLOOD ATTACK)是指利用计算机网络技术向目标主机发送大量无用的数据报文，使得目标主机忙于处理无用的数据报文而无法提供正常服务的网络行为！如果高并发，linux内核会判断为是洪水攻击行为，会自动为我们抵御这种它认为是洪水攻击的行为，其实不是！
那么我们就要关闭这行机制！
echo 0 > /proc/sys/net/ipv4/tcp_syncookies

打开的文件数量层面：

nginx层面：
打开nginx配置文件
子进程允许打开的文件数量（给他10000个）：

系统层面：
上边讲过了随着2开始写的第3个就是
执行命令：
ulimit -n 20000
测压：
ab -n 100000 -c 5000 http://192.168.1.168/index.html
看结果：失败次数0 你可以搞到20万次请求1万个并发或者更高试试