CPU 使用率升高会影响整个实例集群的吞吐量,甚至可能会导致应用阻塞,超时中断。当平均 CPU 使用率高于60%或者 CPU 平均峰值使用率高于90%且持续时间超过5分钟时,您需要及时排查具体原因,针对性快速解决问题,以保障业务稳定性和可用性。
现象描述
现象1:收到 CPU 使用率过高的消息提醒:
现象2:CPU 使用率的监控指标高。
现象3:整体吞吐量变小、响应速度变慢。
排查与解决
序号 | 可能原因 | 原因分析 | 排查方法 | 解决方法 |
1 | 频繁建立短连接 | 实例大量资源消耗在处理频繁短连接上,引起 CPU 使用率较高,连接数较高,然而 QPS(集群每秒访问次数)未达到预期。 | ||
2 | 存在高时间复杂度的命令。例如:sort、sunion、zunionstore 等。 | Redis 是单线程执行命令,执行复杂度高的命令,很可能阻塞其他命令。命令的时间复杂度越高,在执行时会消耗较多的资源,会引起 CPU 使用率上升。 | 使用复杂度较高命令,每次不要获取太多的数据,尽量操作少量的数据,让 Redis 可以及时处理返回。 | |
3 | 读写负载过高,如存在对热点 Key 的大量访问或者存在大 Key。 | 热 Key 指的是那些在一段时间内访问频率特别高的键值。具体到业务场景,包括热点新闻、热门直播、秒杀活动等等。大量访问流量集中到一个实例中,达到单个实例的处理上限,引起 CPU 使用率上升。 | 热 Key:拆分复杂数据结构,将热点 Key 拆分为若干个新的 Key 分布到不同 Redis 节点上,从而减轻压力。以哈希类型为例,该热 Key 的类型是一个二级数据结构,该哈希元素个数可能较多,可以考虑将当前 hash 进行拆分。 | |
4 | | 大 Key 指某个 Key 对应的 value 很大,占用的 Redis 空间很大。执行大 Key 相关读取或者删除操作时,会严重占用带宽和CPU。 | 大Key:如果是 value 过大,您可以将对象拆分成多个 key-value,将操作压力平摊到多个 Redis 实例;如果是 Key 过多,您可以参考 hash 结构存储,将多个 Key 存储在一个 hash 结构中。 | |
5 | | 读负载过高,达到资源上限。 | ||
6 | | 写负载过大,内存规格不足。 | | 写负载过大:您可以通过 增加分片数量 的方式来分摊写负载。若实例为标准架构,请优先升级标准架构为集群架构,提升 CPU 处理能力。具体操作,请参见 升级实例架构。升级集群架构之前需要检测兼容性,请参见 标准架构迁移集群架构检查。 |
7 | 同一时间点大量的 Key 过期。 |
Key 过期时间设置在同一时间点,到达过期时间点,Redis 将占用较大 CPU 资源处理 Key 的淘汰线程,引起短暂卡顿。
|
在业务逻辑中,分散过期时间,避免 Key 集中过期。
| |
8 | 频繁切换 DB,即频繁执行 select 命令进行 DB 切换。 | 频繁切换 DB,带来资源的过度开销。 | 如果存储不同业务,针对频繁切换 DB 的业务,建议分开存储。 如果存储相同业务,评估 Key名不冲突的前提下,考虑将数据存储在相同的 DB,减少 select 请求操作次数。 |