首页 » 技术分享 » 总结一次系统宕机问题

总结一次系统宕机问题

 

@ 总结一次系统宕机问题(大神可以忽略,本篇文章给小白们指条明路)

问题简单描述:

2019年9月6号12点左右,在公司楼下吃饭,突然接到了公司运营的电话,反馈系统宕机,系统服务全部停止,别的不说上截图

在这里速度插入图片描述首先进入日志发现后台的dubbo服务全部阻塞,线程全部占满,导致系统全面宕机(系统架构 SpringBoot+mbs+dubbo+redis)首先查看系统快照以及cpu占用率查看问题,发现全部服务阻塞。排查时间大约10分钟左右,突然灵机一动,想查看一下生产数据库,查看cpu以及占用内存,

在这里插入图片描述突然吓傻了,cpu竟然以笔直的形式冲上了百分之100,所有的问题一刹那解开,初步排查问题:有一条或多条慢sql查询或者别的操作,将数据库cpu拉满,导致阻塞了除了用到redis之外的服务,数据库宕机是罪魁元首,导致所有关于数据库的操作全部等待响应,在控制台将所有sql进程kill掉,cpu直线下滑。。。jenkins重启双节点,服务重新运行。。。满身大汗。。。。

开始排查问题

将rds数据库上的慢sql全部导出,发现有一条sql运行了0.9秒左右,并且查询cpu以及该sql运行大致时间发现符合事故发生时间

在这里插入图片描述突然纳闷了,为什么一条update没有连表,竟然执行时间竟然会达到0.9秒,我蒙了,身为3年程序猿,竟然会在这个sql翻车???,仔细排查发现正常的单表update只需要0.03~0.05秒左右。。。为什么这个update会执行如此之久。。。

在这里插入图片描述排查后发现正常的update 是通过id 来进行的,但是我这条sql是通过用户的openId来修改用户的关注公众号状态,但是这个openId未建立索引。。竟然会运行0.9秒以上…果断增加数据库索引

在这里插入图片描述运行时间直接下滑到0.06秒,唉。。。。心累,
只怪当初偷懒,没加索引,导致系统宕机,以及扣除百分之40绩效。。。哭了

问题总结

1.除非是通过id进行update ,否则大批量数据表中,要在合适的地方新增索引增加查询以及修改速度!!!

2.想明白为什么通过该字段进行update操作,可不可以 通过表主键id进行查询以及修改操作。。。

3.最重要一点,遇到事情不要慌,昨天中午差点吓尿了,公司ceo直接拍我肩膀说怎么样。。留我一个人在风中凌乱。。。。

在这里插入图片描述
感谢大家观看,小弟献丑了,以后我会多多分享项目经验以及踩坑经验。还有关于阿里云iot以及java问题可以私信评论,我可以和大家一起解决。再次感谢。。

转载自原文链接, 如需删除请联系管理员。

原文链接:总结一次系统宕机问题,转载请注明来源!

0