系统： centos7
韶光： 2022.02.18_19:30:28 至 23:30
问题：ECS后端相应超时10秒至30秒，http状态码有499和502非常。
定位流程： 检讨CDN流量、SLB负载均衡、ECS后端、数据库和缓存Redis
ELK查询非200的韶光段
一、检讨CDN流量
CDN流量增加50%,问题不在于这里，跟市场的童鞋沟通这个推广量也属于正常。
二、检讨SLB负载均衡监控正常
三、检讨ECS做事器
zabbix和阿里云的云监控并没有负载报警，查看做事器负载，也属于正常
nginx后端相应时长在10-30秒，很多要求超时，数据库也无报警。
于是判断是由于web做事器无法应对流量，增加于是增加2台ECS数据，配置nginx和文件同步，加入SLB负载中问题依然没有办理。
四.检讨数据库
RDS无报警，cpu和内存利用率都正常
总连接数有非常
show full processlist;
查看
搜索，查询更根本的方法，还是从以上三点排查之：
1.程序中，不该用持久链接，即利用mysql_connect而不是pconnect。
2. 程序实行完毕，该当显式调用mysql_close
3.只能逐步剖析系统的SQL查询，找到查询过慢的SQL,优化之
有很多sleep连接，疑惑是后端PHP程序连接数据库没有正常的关闭，统计nginx最多的链接，发给后端修正。
修正地方：
1.修正缺点的数据库配置，数据库名字写错了
2.暂时关闭要求量大的功能（uid判断用户是否被封的轮询接口）
上线之后sleep还是很多，可能连接数一时下不了，等待了半小时，手动kill掉sleep进程。
select concat('KILL ',id,';') from information_schema.processlist where user='apim_user';
业务逐步正常。
数据库增加配置
数据库RDS从2核4G升级为 4核8G，数据库新增一个从库，架构改为主从模式，代理读写分离。
四.redis正常
告警邮件和短信
总结：
运用层
在访问的时候数据库访问报错，然后直接抛出了非常，这样可能导致了数据库链接没有能及时地开释掉，
再加上轮询接口一贯在访问用户库压力大就导致了涌现本日的结果
数据层
提前知晓市场的推广操持，做到未雨绸缪。
