tencent cloud

文档反馈

CPU 使用率过高

最后更新时间:2024-03-01 10:56:27
    CPU 使用率升高会影响整个实例集群的吞吐量,甚至可能会导致应用阻塞,超时中断。当平均 CPU 使用率高于60%或者 CPU 平均峰值使用率高于90%且持续时间超过5分钟时,您需要及时排查具体原因,针对性快速解决问题,以保障业务稳定性和可用性。

    现象描述

    现象1:收到 CPU 使用率过高的消息提醒:
    
    现象2:CPU 使用率的监控指标高。
    现象3:整体吞吐量变小、响应速度变慢。

    排查与解决

    序号
    可能原因
    原因分析
    排查方法
    解决方法
    1
    频繁建立短连接
    实例大量资源消耗在处理频繁短连接上,引起CPU 使用率较高,连接数较高,然而 QPS(集群每秒访问次数)未达到预期。
    借助数据库智能管家 DBbrain 的诊断优化功能,分析数据库实例的实时会话统计视图及数据,确认是否存在连接数突增的现象。具体查询方式,请参见 实时会话
    将短连接调整为长连接,例如使用JedisPool 连接池连接。具体代码示例,请参见 Jedis 客户端
    2
    存在高时间复杂度的命令。例如:sort、sunion、zunionstore等。
    Redis 是单线程执行命令,执行复杂度高的命令,很可能阻塞其他命令。命令的时间复杂度越高,在执行时会消耗较多的资源,会引起CPU 使用率上升。
    执行高复杂度的命令,通常比较耗时,会相应产生慢日志。可借助数据库智能管家 DBbrain 的诊断优化功能进行慢日志分析,在慢日志信息列表中,查看是否存在高复杂度的命令。具体操作,请参见 慢日志分析
    使用复杂度较高命令,每次不要获取太多的数据,尽量操作少量的数据,让 Redis 可以及时处理返回。
    3
    读写负载过高,如存在对热点 Key 的大量访问或者存在大 Key。
    热 Key 指的是那些在一段时间内访问频率特别高的键值。具体到业务场景,包括热点新闻、热门直播、秒杀活动等等。大量访问流量集中到一个实例中,达到单个实例的处理上限,引起 CPU 使用率上升。
    可借助数据库智能管家 DBbrain 的诊断优化功能进行热 Key 分析,快速发现访问频次高的热 Key。具体操作,请参见热 Key 分析
    热 Key:拆分复杂数据结构,将热点 Key 拆分为若干个新的 Key 分布到不同 Redis 节点上,从而减轻压力。以哈希类型为例,该热 Key 的类型是一个二级数据结构,该哈希元素个数可能较多,可以考虑将当前 hash 进行拆分。
    4
    大 Key 指某个 Key 对应的 value 很大,占用的 Redis 空间很大。执行大 Key 相关读取或者删除操作时,会严重占用带宽和 CPU。
    可借助数据库智能管家 DBbrain 的诊断优化功能进行大 Key 排查,针对数据库大 key 占用内存的情况进行监控分析。具体信息,请参见内存分析
    大 Key:如果是 value 过大,您可以将对象拆分成多个 key-value,将操作压力平摊到多个 Redis 实例;如果是 Key 过多,您可以参考 hash 结构存储,将多个 Key 存储在一个 hash 结构中。
    5
    读负载过高,达到资源上限。
    借助数据库智能管家 DBbrain 的诊断优化功能,查看数据库实例性能趋势视图,分析 QPS、读写请求指标,确认是否由于读负载或者写负载过大导致 CPU 使用率偏高。具体信息,请参见 性能趋势
    读负载过高:通过增加副本数量 来分摊读负载。开启副本只读,把当前实例的读请求转移在副本只读节点上,实现读取能力的弹性扩展,提升读写性能。具体操作,请参见 开关读写分离
    6
    写负载过大,内存规格不足。
    写负载过大:您可以通过 增加分片数量 的方式来分摊写负载。若实例为标准架构,请优先升级标准架构为集群架构,提升 CPU 处理能力。具体操作,请参见 升级实例架构。升级集群架构之前需要检测兼容性,请参见 标准架构迁移集群架构检查
    7
    同一时间点大量的 Key 过期。
    Key 过期时间设置在同一时间点,到达过期时间点,Redis 将占用较大 CPU 资源处理 Key 的淘汰线程,引起短暂卡顿。
    在控制台系统监控页面,排查指标key 过期数,确认是否某个时间点有大量的 Key 过期。具体操作,参见 5秒监控更新说明
    在业务逻辑中,分散过期时间,避免 Key 集中过期。
    8
    频繁切换 DB,即频繁执行 select 命令进行 DB 切换。
    频繁切换 DB,带来资源的过度开销。
    借助数据库智能管家 DBbrain 的延迟分析功能,对命令字分析中 select 命令的监控数据进行确认,确认是否存在 select 请求比较多的现象。具体查询方式,请参见 命令字分析
    如果存储不同业务,针对频繁切换 DB 的业务,建议分开存储。
    如果存储相同业务,评估 Key 名不冲突的前提下,考虑将数据存储在相同的 DB,减少 select 请求操作次数。
    
    
    
    
    
    
    联系我们

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

    技术支持

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

    7x24 电话支持