在业务服务提供能力的时候,常常会遇到CPU飙高的问题,遇到这类问题,大多不是数据库自身问题,都是因为使用不当导致,这里记录下业务服务如何定位数据库CPU飙高问题并给出常见的解决方案。
CPU 使用率飙升根因分析
在分析CPU使用率飙升根因前,先介绍下CPU使用率公式:
单位时间 CPU 资源 = 查询执行的平均成本 x 单位时间执行的查询数量
可见,CPU使用率与【查询执行的平均成本】和【单位时间执行的查询数量】线性相关,而这两项就是我们常说的慢SQL以及数据库QPS。
所以,CPU使用率飙升可归纳为以下两点:
(1) 大量的慢SQL占用了cpu资源,拖垮了数据库,这类的慢sql常常表现为:查询的数据量过大,全表扫描、锁抢占甚至死锁、复杂查询等。
(2) QPS过高,本质上是数据库的承载的流量过大。
QPS过高问题定位及解决
如果想判断是否是因为QPS过高,导致CPU飙升,最好的方式是查看QPS曲线和CPU曲线是否保持一致,如果QPS曲线基本和CPU曲线保持一致,此时可断定CPU飙升必然存在QPS过高的原因。示例如下:
接下来就是确认是哪些SQL的QPS过高。对于MySQL数据库,可以通过root用户登录数据库,然后执行’SHOW PROCESSLIST’命令查看。
确定了高频SQL,接下来就是对业务进行分析,确认下为什么会执行如此频繁的调用并给出优化方案。
(1) 使用批量操作,将多个操作合并为一次请求,但此种方式需要考虑是否可以一次批量的数据有多大,避免造成慢SQL。
(2) 尽量从缓存中获取常用的查询结果,减轻数据库的读写压力。
(3) 尽量优化查询,减少查询的执行成本(逻辑 IO,执行需要访问的表数据行数),提高应用可扩展性。
(4) 定期归档历史数据、采用分库分表或者分区的方式减小查询访问的数据量。
(5) 增加只读实例,将对数据一致性不敏感的查询(比如商品种类查询、列车车次查询)转移到只读实例上,分担主实例压力。(读写分离)
(6) 升级实例规格,增加 CPU 资源。(首先确认是资源不足,然后才考虑扩资源)。
慢SQL问题定位及解决
一般情况下,数据库都会提供慢查询日志,所以只需根据慢查询日志来确定慢SQL接口。以MySQL为例,可以通过root用户登录数据库,执行SHOW VARIABLES LIKE 'SLOW_QUERY_LOG%'命令来查看慢日志的路径。
在指定路径下获取到慢查询日志后,接下来就是分析慢日志,确认慢SQL。
分析慢查询日志,发现有一条SQL的执行时间超过2S。进一步使用explain查看执行计划,发现执行时间的确很长。
确定了慢SQL后,接下来就是对SQL进行分析,确定下优化方案。关于数据库访问性能的优化可以参考笔者之前的文章,这里列举下常用处理方式:
(1) 减少数据访问。确认下是否使用索引,如果没有,看看是否可以补充索引。如果已使用索引,确认下索引是否生效或失效。
(2) 减少返回的数据。如果没有使用分页,确认是否可以使用分页。如果返回字段包含大字段或字段,确认下是否可以分表或仅返回需要使用的字段。
(3) 减少交互次数。确认下是否可以引入批量操作,或提高单次fetch数据的size。
(4) 减少数据库CPU开销。针对大量的计算,确认下是否可以转移到客户端执行。针对排序场景,确认下是否有优化空间。
(5) 针对读多写少场景,考虑使用读写分离的设计。
(6) 升级下机器的资源配置。考虑是否机器的本身性能较低,不符合业务需求。
总结
本文介绍了数据库CPU飙高问题定位及解决,重点介绍了如何判断慢SQL和QPS过高。需要说明的是,以上内容是笔者基于网上的知识整理的内容,笔者并没有太多这方面的实践经验。但是,上述定位问题的思路和解决方案是有参考价值的。比如使用缓存减少数据库读写次数、批量操作、机器资源配置升级等方案,笔者在实际的产品维护中,都有使用。
参考
https://www.cnblogs.com/jyc123/p/16498247.html 数据库CPU使用率100% 排查记
https://blog.csdn.net/yw804909465/article/details/106445902 Mysql数据库高CPU问题定位和优化
https://www.cnblogs.com/wyy123/p/9258513.html MySQL CPU 使用率高的原因和解决方法
https://www.modb.pro/db/31741 mysql QPS 过高问题处理
https://www.cnblogs.com/wyy123/p/9258513.html MySQL CPU 使用率高的原因和解决方法