高并发服务须要关注的点

系统负载篇：

一，什么是Load Average?

系统负载（System Load）是系统CPU繁忙程度的度量，即有多少进程在等待被CPU调度（进程等待队列的长度）。
平均负载（Load Average）是一段时间内系统的平均负载，这个一段时间通常取1分钟、5分钟、15分钟。

二，如何查看Load?

1, cat /proc/loadavg

2, uptime

3, top

以上三种方式均可以查看当前系统的负载，而load average: 0.95, 0.94, 0.92 后边这三个数字是最回味无穷的

他们按照前后顺序依次表征一分钟，五分钟，十五分钟的系统平均负载（其实就是这三个时间段真正在忙碌的进程即CPU有多少个）

三， 如何评估当前系统的平均负载水平？

分割的界限：通常有经验的系统管理员会将负载饱满这条标准定在70%。（即忙碌的CPU占服务器总核数的百分比）

当前，咱们线上服务器通通采用的是64核（vcpu）的ECS，而xadserver经过uwsgi起服务时，指定的进程数为45，让咱们来换算一下比例：45 / 64 = 0.703125

因此咱们当前起服务的进程数刚恰好是略超70%标准线

咱们再去线上读一下负载水平：

1，5，15三个时段的活跃CPU大概为45，与进程数相同，因此咱们服务器的负载由于咱们的进程数会保持在70%左右（服务正常的前提下）

图中负载较低的时段为每日请求数较少的时段，由图线趋势可知，每日晚9点至第二天凌晨5点请求数持续下降，以后再持续升高，最高系统负载由服务的45个线程决定系统负载

上图为事故当天系统负载的曲线变化

11点开始并发较高，而当时因为重启服务的缘由，slb将并发压力分摊到其他5台机器上，致使其他5台机器系统负载升高（但并无超出64核的限制，因此负载升高只是服务被击穿的表象，并非根本缘由，但能够做为佐证的一个参考依据）

服务被击穿后，系统负载的变化曲线忽高忽低，暂无肯定结果，私觉得服务被击穿后，实时处理的客户端请求急剧下降，没法正常返回，故曲线骤降，而负载降至冰点后，大量客户端重试请求和正常请求涌入，再次击穿服务，如此往复致使曲线骤降骤升

 

 

TCP篇：

在Linux平台上，不管编写客户端程序仍是服务端程序，在进行高并发TCP链接处理时，最高的并发数量都要受到系统对用户单一进程同时可打开文件数量的限制(这是由于系统为每一个TCP链接都要建立一个socket句柄，每一个socket句柄同时也是一个文件句柄)。

 

对于文件句柄的数量有三层限制

1，软限制：Linux在当前系统可以承受的范围内进一步限制用户同时打开的文件数

2，硬限制：根据系统硬件资源情况(主要是系统内存)计算出来的系统最多可同时打开的文件数量（一般软限制小于或等于硬限制。）

3，系统限制：当前Linux系统最多容许同时打开(即包含全部用户打开文件数总和)文件个数，是Linux系统级硬限制，全部用户级的打开文件数限制都不该超过这个数值。一般这个系统级硬限制是Linux系统在启动时根据系统硬件资源情况计算出来的最佳的最大同时打开文件数限制，若是没有特殊须要，不该该修改此限制，除非想为用户级打开文件数限制设置超过此限制的值

软硬限制：/etc/security/limits.conf   -→ 文件中的soft nofile/hard nofile

系统限制：cat /proc/sys/fs/file-max

当前这三个限制在咱们线上机器设置的数量均为 655350

因此咱们线上单台服务器理论上最高并发支持 655350（实例支持的真实最大并发与服务器的硬件配置和网络环境有关）

事故当天单台ECS实例的TCP链接中 ESTABLISHED 数量在24000 - 25000之间，总的TCP链接数数量保持在 90000 - 100000之间，总TCP链接数-ESTABLISHED链接数=TIME_WAIT链接数 + CLOSE_WAIT链接数（其余类型的TCP状态影响较小，暂不考虑）

处于TIME_WAIT和CLOSE_WAIT状态的TCP链接会占用当前系统的文件句柄，影响系统的并发处理能力，而当前线上服务器对于TIME_WAIT处理的系统配置文件已是优化过的，因此该事故的直接缘由是TCP链接数超过了系统实际可承载的最大链接数

在服务正常运转时，单台服务器的 ESTABLISHEED链接数为9000-10000，总的TCP链接数数量保持在45000 - 60000之间

 

综上计算当前slb并发：9500 * 10 = 95000

查询slb并发链接数，当前slb的活跃链接数与每台ECS实例的ESTABLISHED状态TCP链接数总和数量级相同

 

监控篇：

系统负载只是线上服务出了问题以后的一种现象，而要作到提早发现就是监控ECS实例的TCP链接状况，对于不健康的TIME_WAIT以及CLOSE_WAIT提早发现（其实最终仍是监控当前系统的TCP总链接数）

监控命令：netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

上边是一台线上机器的TCP链接状况，能够看到ESTABLISHED状态的链接数目前为9000数量级，而TIME_WAIT高达40000，这是一种正常状况

由于咱们的服务属于 高并发短链接，当服务器处理完请求后会马上主动正常关闭链接，这个场景就会出现大量socket处于TIME_WAIT状态，而咱们线上服务器已经针对此业务场景优化过系统配置

而最终形成TCP链接过多打挂服务的直接缘由就是总的TCP链接数占据过多文件句柄，超出系统承受范围。

 

因此预防线上ECS没法承受预期以外的高并发，就须要提早监控ECS的当前TCP总链接数，设置阈值，提早报警。