系统负载篇：
一，什么是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总连接数，设置阈值，提前报警。