tencent cloud

文档反馈

CPU 利用率过高

最后更新时间:2023-02-22 16:15:00

    现象描述

    云数据库 MySQL 出现响应变慢、无法获取连接、超时等现象。当云数据库 MySQL CPU 利用率超过80%时,可能会出现业务响应变慢、超时、无法连接数据库等现象。

    云数据库 MySQL CPU 使用情况,可在 MySQL 控制台 的实例监控页面或数据库智能管家 DBbrain 控制台 查看。

    说明:

    CPU 利用率过高时,建议优先进行 配置调整,提升 CPU 规格以确保业务正常运行,后续可参考本文进行排查和优化。

    故障风险

    若 MySQL CPU 的利用率长时间处于过高状态,会严重影响数据库的整体性能,极端情况下可能会出现实例 HANG 住的情况。

    当 HA 探测到实例 HANG 住后,为了保证用户业务的高可用性,会触发主备切换,在主备切换的过程中,业务会出现短时间的不可用,实例不可用的时长正常情况下不超过60秒。如在业务高峰期发生了主备切换,会严重影响业务的稳定和连续性。

    为避免业务因 CPU 资源不足而受影响,建议提前对 CPU 利用率过高的实例进行业务优化或者升级 CPU 资源。实例发生主备切换时会出现秒级的闪断,对于长连接需要应用具备重连的机制。

    可能原因

    MySQL 主要是两类线程占用 CPU:系统线程和用户线程。因此 MySQL 独占的云服务器上,仅需关注这两类线程的情况,就能解决大部分的故障场景。

    用户线程

    用户线程繁忙,大部分场景都是由“慢查询”引起的,除“慢查询”因素外,还有“计算量大”和“高 QPS”因素。

    • 慢查询
      进行长时间的计算,例如:order by,group by,临时表,join 等。这一类问题是查询效率不高,导致单个 SQL 语句长时间占用 CPU 时间。
    • 计算量大
      单纯的数据量比较多,导致计算量巨大。
    • 高 QPS(Queries Per Second )
      单纯的 QPS 压力高,所以 CPU 的时间被用满了,如:4 核的服务器用来支撑 20k 到 30k 的点查询,每个 SQL 占用的 CPU 时间并不多,但是因为整体的 QPS 很高,所以 CPU 的时间被占满了。

    系统线程

    在实际的环境中,系统线程遇到问题的情况会比较少,一般来说,多个系统线程很少会同时跑满,只要云服务器的可用核心数大于等于 4 ,一般也不会遇到 CPU 利用率过高,当然有一些 bug 可能会有影响,如下图所示:

    解决思路

    大部分故障场景,基本是用户线程繁忙导致,因此本文主要介绍用户线程导致的 CPU 利用率过高问题,提供对应的解决方案。

    • 慢查询:建议使用 DBbrain 来排查和优化,详情请参见 慢查询
    • 计算量大:因处理数据量大,导致 CPU 利用率过高,处理措施详情请参见 计算量大
    • 高 QPS:因访问量过大,导致 CPU 利用率过高,处理措施详情参见 高 QPS

    处理步骤

    慢查询

    导致 CPU 利用率过高的异常 SQL 语句,可以使用数据库智能管家 DBbrain 来排查和优化:

    MySQL 慢查询时间(long_query_time)的默认值是10s,在遇到性能问题时,若发现没有慢查询,建议将其参数调成1s ,再观察业务周期内的慢查询,进而对其慢查询进行优化。若参数调整后,在其业务周期内依然未发现慢查询,而 CPU 利用率依然偏高,建议升级 CPU 的配置,进而提高数据库的整体性能。

    计算量大

    若数据量比较大,即使索引和执行计划没什么问题,也会导致 CPU 利用率过高,而且结合 MySQL one-thread-per-connection 的特性,并不需要太多的并发就能把 CPU 使用率跑满。

    一般来讲,这类问题有如下两种比较常规的解决方案:

    • 读写分离,把这一类查询放到平时业务不怎么用的只读从库去。
    • 在程序段拆分 SQL,把单个大查询拆分成多个小查询。

    高 QPS

    • 升级 CPU 的配置,进而提高数据库的整体性能。
    • 挂载只读实例,分担主实例压力。
    • 优化查询语句,提升执行效率。
    联系我们

    联系我们,为您的业务提供专属服务。

    技术支持

    如果你想寻求进一步的帮助,通过工单与我们进行联络。我们提供7x24的工单服务。

    7x24 电话支持