CPU 使用率过高

最近更新时间：2023-05-22 10:34:21

我的收藏

本页目录：

现象描述
排查与解决

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 请求操作次数。 
﻿
﻿
﻿
﻿
﻿
﻿

上一篇: Redisson 客户端超时重连异常分析及解决方案下一篇: 出流量过高

序号	可能原因	原因分析	排查方法	解决方法
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 请求操作次数。