数据库CPU使用率100% 排查记

阅读量:

1.背景:

在监控线上数据库的运行是否安全、正常的过程中,cpu 使用率是一个重要的指标,一旦cpu使用率飙升至90%+甚至达到100%,必然会对数据库的正常工作产生影响。

在排查数据库的cpu 飙升的问题前,我们先看下cpu 飙升的原因有哪些。

2.cpu使用率飙升的原因

首先直观的,cpu使用率过高可能和流量和慢查询有一定的关系

进一步查阅相关资料,得到公式:单位时间 CPU 资源 = 查询执行的平均成本 x 单位时间执行的查询数量

显然,cpu使用率与【查询执行的平均成本】和【单位时间执行的查询数量】线性相关,而这两项就是我们常说的慢sql以及数据库QPS。

所以:一般而言,cpu使用率飙升可归纳为以下两点:

  • 大量的慢sql占用了cpu资源,拖垮了数据库,这类的慢sql常常表现为:查询的数据量过大,全表扫描、锁抢占甚至死锁、复杂查询等
  • QPS过高,本质上是数据库的承载的流量过大

3.如何解决

3.1 定位问题

定位是否为qps原因:

例如以下案例:

首先,查看当前cpu曲线:

发现此时的cpu已经解决100%在运行,再查看此时的qps曲线,

会发现此时的qps曲线基本和cpu曲线保持一致,此时我们可断定cpu飙升必然存在qps过高的原因。为了验证是否有慢sql的存在,再查看慢sql曲线:

发现此案例中完全不存在慢sql。因此责任可100%归为qps过高,如果我们对该库所在实例开通的sql审计的功能,我们可查看过去一个月的qps记录,判断是由哪台机器发出的高频请求,以及请求的Top调用量的sql。

如果我们没开通sql审计功能的话,阿里云也可查看当前对库的实时请求记录,或者我们可以以root用户登陆数据库,执行‘SHOW PROCESSLIST’命令查看。

最后 定位了具体sql或者接口后 就可以针对性的解决问题:降级或者限流。

定位是否为慢sql原因

案例1 CPU峰刺

例如以下案例:

首先,查看当前cpu和qps曲线:

从上图我们可看出,cpu和qps的整体的整体走势是基本一致的,但是上图中相对qps曲线,cpu有好几次的抖动,甚至峰值达到80%,我们需要排查出这些峰刺点。

由于此时的cpu抖动和qps曲线不一致,可推测是慢sql引起的,观察下图抖动时间段内的慢sql,确定是否有慢sql,以及慢sql的具体信息。

观察上图发现该时间段内一些慢sql在库上使得cpu曲线发生了抖动,此时可采取kill+id的方法定制该sql的执行。

案例2 CPU明显飙升

有时,我们会发现cpu和qps的曲线不够吻合,此时我们有较大的把握推测出原因就是慢sql引起的。如以下情况:

红框内的cpu使用率在上升,但qps却在下降,观察以下慢sql监听:

说明这段时间内的异常是100%是由慢sql引起的,可采取kill+id的方法定制该sql的执行。

4 总结

4.1 慢sql优化思路

慢sql的优化思路较多,本文不打算赘述,仅提供以下几个方面优化思路。

  • 1.扫描数据库记录数较多。

考虑表是否设置了合理的索引,表字段是否设置了合理的数据类型,sql是否有效的利用了索引等。

  • 2.sql中是否有做了大量的聚合、计算?

考虑将sql简化,把逻辑操作上浮到业务中去做。

  • 3.sql返回的记录数过多。
    考虑分页实现,通过limit将一次请求转为多次请求。

  • 4.表中是否冗余字段过多?
    表若为宽表,包含大量冗余字段,可考虑分表。

  • 5.库中是否有很多张表?
    此时可考虑将表拆分到多个库中,分库。

  • 6.若库的读写较多,锁争抢激励,甚至死锁。
    可考虑多库做读写分离。
  • 7.机器的本身性能较低,不符合业务需求。
    可考虑机器升级了。

4.2 qps过高优化思路。

  • 1.qps过高时,考虑是否可以使用缓存。
  • 2.使用批量操作,将多个操作合并为一次请求,但此种方式需要考虑是否可以一次批量的数据有多大,避免造成慢sql。
  • 3.考虑分库、读写分离,减少对一个机器的访问压力。
  • 4.机器升级,没什么是钱解决不了的。

Cover Pic by Kevin Ku on Unsplash


comments powered by Disqus