关于立维
站群应用并发
如何解决异常报警情况?
20点01分收到一个平时很少更新的网站报警,接着跟他关联的业务也发生报警,第一感觉是是不是客户在更新系统,但紧接着,一堆网站出现异常。
1. 首先从大量的网站出现异常上分析,这些应用有什么共通性,是否用了同一个nginx,或者同一台主机,或者同一个数据库。
2. 分析后发现,这些应用都用到了Nginx,应用大多部署在Storemax_OP_01主机上
3. 基于上述两点,我们就要分析nginx是不是挂了,80端口是不是不通
4. 发现nginx一切正常
5. 查看nginx的监控,发现如下两种现象,带宽满了,和nginx并发达到了6000
6.分析nginx日志,查看是否为攻击,由于开始时不知道几十个站点里面,哪个业务出了问题
cat *.access.log|grep "18/Sep/2016:20:0[1-9]"|awk '{print $7}'|sort -rn|uniq -c|sort -rn|head -n10
根据查找出来的访问较高的URL,再去查是哪个应用,由于瞬间产生这么大的访问量,日志的大小肯定会很大。而这些站群中,日志量大的应用不多,很快就查到了是www.storemax.cn这个应用触发的。
1. 临时增加一个集群(3分钟时间)
2. 客户那边重启了应用对应的数据库服务器
1. 访问频次分析
时间 | IP数 | 请求数 |
2016:20:0[0-9] | 721 | 102915 |
2016:20:1[0-9] | 949 | 92154 |
2016:20:2[0-9] | 812 | 71881 |
2016:20:3[0-9] | 786 | 45769 |
2. 用户Agent属性分析
从分析结果上看,agent没有
cat www.storemax.cn.access.log|grep "18/Sep/2016:20:[0-2]"|awk '{print $13,$14,$15,$16,$17,$18,$19,$20,$21,$22,$23}'|sort -rn|uniq -c|sort -rn|head -n10
3. 分析agent数过多的访问IP地址来源
cat www.storemax.cn.access.log|grep "18/Sep/2016:20:[0-2]"|grep "iPhone OS 9_3_5 like Mac OS X) AppleWebKit/601.1.46" |awk '{print $1}'|sort -rn|uniq -c|sort -rn|head -n10
4. 分析IP数最多的请求信息
cat www.storemax.cn.access.log|grep "18/Sep/2016:20:[0-2]"|grep "121.32.33.50"|more
从显示的日志上看,用户属于正常访问行为。
可以基本得出结论,是由于活动推广导致的用户并发突增,从而导致业务不可用。
既然是业务量增大导致的不可用,我们又该如何去优化架构?
是不是增加应用集群就够了?
电话沟通中,客户的业务架构很简单,IIS+SqlServer服务,POST的请求基本都是都是对数据库的操作,有查询,也有插入。
那问题就变得简单了
我们统计这段时间的对数据库的操作的大概次数
时间段 | POST次数 |
2016:20:0[0-9] | 8639 |
2016:20:1[0-9] | 13716 |
2016:20:2[0-9] | 9407 |
2016:20:3[0-9] | 6075 |
从POST的统计结果来看,是有一定的量,但也不排除数据库中存在SQL性能瓶颈。
1. 增加应用集群
2. 增加数据库查询数热点,使用redis或者memcache进行缓存
3. 增加数据库的监控,进一步分析数据库中性能瓶颈
看到这里,小伙伴们有没有觉得茅塞顿开呢?
未来我们还将继续为大家带来技术难题的解决方法
帮助同行的小伙伴们
解决疑难杂症
增长学习经验
摆脱思路困境
丰富实战案例
提供最好的帮助!!!
相信立维,我们还能为你做得更多!
要运维,找立维!
立维,您身边的运维专家!
相关文章