DB常见问题排查方法

时间:2023-03-08 17:46:37

一般情况下,系统多多少少都会遇到点问题,那么遇到问题之后我们怎么定位原因呢?在这里我只说如何定位DB的问题。

看这篇文章有个前提:监控数据要完整!监控数据要完整!!监控数据要完整!!!
比如下面这个
DB常见问题排查方法
乍一看,有个性能抖动,如何知道系统是不是有问题,可以通过以下途径知悉:

  • 应用日志
  • 监控报警
  • 用户感知

无论是监控报警,还是用户感知,归根结底还得回归应用,从应用日志发现到底是哪个接口异常,接口异常的原因无外乎以下几种情况:

  • 系统异常,比如超出负载
  • 网络问题,比如网卡爆满,网络丢包
  • io问题,比如刷磁盘,io调度算法设置问题
  • 文件系统问题,比如内核bug
  • DB问题,比如包含上面的几种情况,烂SQL问题

假如说上面几种情况排查完毕后没有异常,或者通过日志一眼就发现是DB问题,到底是什么问题呢?通常情况下,我会这样做:

  1. 打开监控页面查看"性能"

如果没有监控,我也没办法了,只能根据应用报错猜了。

下面请睁大眼睛:
1. 查看出问题时间点整体性能
2. 通过异常,找出问题点
《医学的真相》说:“在医学中很多突破都是从研究例外开始。”

老罗也说“在平常的学习中,最珍贵的东西不是那些符合理论的东西,恰恰是那些看着奇怪,例外的东西,现有的理论往往解释不了,你千万不能忽略他,因为它是下一个创新的苗子。” 
这里也不例外,比如先看整体qps,tps有没有变化,网络有没有抖动等等,总之就是发现和其他时间段不一样的趋势。这个就是问题点所在,就拿第一张图举例子,我们看到rt飙高,一般来说rt飙高通常情况有以下几种原因:

  • 烂SQL 线上90%以上基本是这个原因
  • 硬件问题 线上出现过,但是不多
  • 文件系统bug
  • MySQL bug
  • 网络问题

关于烂SQL其实有各种各样的,您可以到网上搜出一大堆,这里就不累述了,以后有时间的话,我可能会写写;

MySQL bug如果排除了烂SQL,有一些诡异的问题是可以怀疑是MySQL的bug的,可以查看bug list

再次是网络问题,如果确定既不是烂SQL,系统的qps很高的话,如果系统有时不时的抖动,可以查看网络监控;

最后网络问题和文件系统问题出现的几率真是少之又少,但也不排除,只能具体问题具体分析了;