记一次因慢查询导致的事故

今天下午17点10分左右,接到技术支持的反馈,代付交易出现异常。查看交易日志发现:内部系统间的dubbo调用超时

于是,找到相关同事了解情况。同事反馈,他们的机器在忙着处理微众二类户的用户的信息上传,导致IO开销过大,可能导致dubbo调用超时,建议重复发起交易。

交易组leader反馈,交易不能受影响,IO开销大的话,就先加机器应对。然后,各自排查问题。

疑似原因
– 因为大量的用户身份信息上传,导致IO开销过大
– 大量的请求和文件传输,导致网络拥堵

开会讨论,最终排除网络拥堵的原因。但,确实存在网络拥堵的现象,紧急扩充带宽。

统计线上的服务器情况,发现CPU以及IO使用,都已经过了峰值,但仍出现大量dubbo超时现象。

最终定位问题为数据库问题。数据库集群的机器,出现慢查询,CPU占用近100%。

总体来讲,因为太久没出现问题,导致所有人都有放松,没人觉得会出现问题。同时也发现了一些问题:

  • 交易日志的警报定位不准确。很多关键位置,没有设置报警
  • 当业务量增长的同时,没有及时把不相关业务分离。A业务增长时,因为占用了大量的IO/CPU计算力,导致B业务受影响。
  • 运维监控的缺失。CPU的使用率达到近100%,没有相关报警
  • 及时的关注业务量,在关键查询上添加有效索引
  • 所有的人,对错误的出现,没有追根究底的习惯

希望自己和看到这边文章的朋友,能够能多的关注系统的整体的流程,不能仅仅拘泥于单点的代码逻辑

发表评论

This site uses Akismet to reduce spam. Learn how your comment data is processed.