DevOps知识中心
DevOps知识中心

Redis 为什么会占用高 CPU？调试与优化技术

调查 Redis（一个关键的内存数据存储）中突发的高 CPU 利用率。本指南详细介绍了如何使用 `SLOWLOG` 和 `INFO` 命令来调试负载，以查明低效的操作，例如 `KEYS *` 或删除大键。学习实用的优化技术，包括切换到异步 `UNLINK`、利用管道（pipelining）以及调整持久化设置，以立即减轻服务器负载并恢复最佳的 Redis 性能。

71 浏览量

Redis CPU 使用率过高的原因：调试与优化技术

Redis 以其闪电般的内存性能而闻名，是缓存、会话管理和实时数据处理的关键组件。然而，当您的 Redis 实例 CPU 利用率突然飙升时，性能会迅速下降，影响所有依赖的应用程序。了解其发生的原因是解决问题的第一步。本指南深入探讨了导致 Redis CPU 使用率过高的常见原因——从低效命令到后台 I/O——并提供了可操作的调试和优化技术，以立即恢复系统健康。

理解 Redis 架构与 CPU 负载

Redis 主要作为一个单线程应用程序来处理核心命令。这意味着大多数操作都在一个 CPU 核心上顺序运行。因此，高 CPU 使用率通常表明该单线程过载，或者后台进程（如持久化或网络 I/O）正在消耗大量资源。

影响 Redis CPU 负载的关键因素

  1. 命令执行时间： 复杂或资源密集型命令会阻塞主线程。
  2. 持久化操作： 将数据保存到磁盘（RDB 或 AOF）可能会导致临时的 CPU 峰值和延迟。
  3. 网络负载： 高流量或低效的客户端行为会给 I/O 处理能力带来压力。
  4. 数据结构开销： 对超大型数据结构进行操作。

调试高 CPU 利用率

在优化之前，您必须准确识别负载来源。监控工具和内置的 Redis 命令对于诊断至关重要。

1. 使用 INFO 和 LATENCY 命令

INFO 命令提供服务器状态的快照。重点关注 CPU 部分和命令统计信息。

redis-cli INFO cpu

查找 used_cpu_sys 和 used_cpu_user 等指标中的高值。高 used_cpu_user 通常指向繁重的命令处理，而高 used_cpu_sys 可能表示内核交互，通常与 I/O 或内存管理有关。

LATENCY 命令可以找出导致持续延迟峰值的命令。

redis-cli LATENCY HISTORY command

2. 使用 SLOWLOG 识别慢命令

Redis 慢查询日志记录了超过指定执行时间的命令。这是您查找性能不佳操作最直接的工具。

配置： 确保在 redis.conf 文件中或通过 CONFIG SET 动态地适当配置 slowlog-log-slower-than（微秒）和 slowlog-max-len。

示例配置：

# 记录执行时间超过 1000 微秒（1 毫秒）的命令
SLOWLOG-LOG-SLOWER-THAN 1000
SLOWLOG-MAX-LEN 1024

获取日志：

redis-cli SLOWLOG GET 10

查看输出，了解哪些命令（例如 KEYS、大型 HGETALL 或复杂的 Lua 脚本）占据了主要的执行时间。

3. 监控网络和客户端活动

谨慎使用 MONITOR 命令（它会产生高开销），或依靠外部工具/操作系统监控（netstat、ss）来检查活动连接的数量和总网络吞吐量。连接或每秒命令的突然激增可能会使单线程不堪重负。

常见原因和优化策略

一旦您确定了有问题的命令或进程，请应用有针对性的优化技术。

1. 消除阻塞命令

在单线程模型中，CPU 峰值的主要来源是阻塞操作。在生产系统上绝不使用扫描整个数据集的命令。

低效命令 为什么导致高 CPU 优化 / 替代方案
KEYS * 扫描整个键空间。时间复杂度为 O(N)。 迭代使用 SCAN 或重构数据访问方式。
FLUSHALL / FLUSHDB 删除所有键。 使用显式删除或 UNLINK（非阻塞删除）来处理大型键。
HGETALL、SMEMBERS（针对超大型集合） 将整个结构检索到内存并进行序列化。 使用 HSCAN、SSCAN，或将大型结构分解为更小的键。

最佳实践：对于超大型键，使用 UNLINK 而不是 DEL。 DEL 在删除键时会阻塞主线程。UNLINK 则在后台异步执行实际删除，显著减少大型键逐出期间的 CPU 负载峰值。

# 代替 DEL large_key
UNLINK large_key

2. 优化持久化 (RDB 和 AOF)

后台保存操作会触发 BGSAVE 命令的使用，该命令利用操作系统的 fork() 机制。在拥有大型数据集的系统上，fork() 可能会占用大量 CPU 和时间，导致短暂但显著的负载。

  • RDB 快照： 如果您频繁保存（例如，每分钟一次），重复的 fork() 调用将导致周期性的 CPU 峰值。减少自动保存的频率。
  • AOF 重写： AOF 重写（BGREWRITEAOF）也占用大量资源。Redis 尝试通过执行最小的 I/O 来优化此过程，但在重写过程中 CPU 使用率会上升。

优化技巧： 如果您在持久化期间遇到无法接受的延迟，请考虑调整 save 间隔或在高峰负载期间短暂暂停持久化，尽管这会增加数据丢失的风险。

3. 处理内存碎片和交换

虽然内存问题通常与高内存使用率相关，但严重的内存碎片，或更糟的是操作系统开始将 Redis 数据交换到磁盘（抖动），将大幅增加 CPU 使用率，因为内核会努力管理内存。

  • 检查交换： 使用操作系统工具（vmstat、top）检查系统是否正在主动交换属于 Redis 进程的内存页面。
  • 内存碎片率： 检查 INFO memory 输出中的 mem_fragmentation_ratio。如果比率显著大于 1.0，则表明存在高度碎片化，这会增加内存分配/释放期间的 CPU 负载。

如果发生交换，解决方案总是减少数据集大小或增加更多物理 RAM，因为 Redis 在交换发生时无法有效运行。

4. 网络优化与管道化

如果 CPU 负载与高命令吞吐量直接相关，则延迟可能是由大量网络往返开销引起的。

管道化： 不要发送 100 个单独的 SET 命令，而是通过您的客户端库将它们组合成一个命令块，使用管道化。这减少了网络延迟和单个 Redis 线程处理的每个命令的开销，从而提高了批量操作的整体 CPU 效率。

持续性能的最佳实践

为了防止未来的 CPU 峰值，请采用以下架构和配置最佳实践：

  1. 使用异步删除： 对于可能很大的键，始终优先使用 UNLINK 而不是 DEL。
  2. 绝不使用 KEYS： 在生产环境中，使用 SCAN 进行键发现。
  3. 监控客户端行为： 确保应用程序开发人员了解他们使用的 Redis 命令的复杂性影响。
  4. 调整持久化频率： 调整 RDB 保存点以避免与高峰流量时间重叠，如果 RDB fork 是主要原因，则更多地依赖 AOF。
  5. 垂直扩展（如有必要）： 如果一个核心在经过优化后仍然持续饱和，请考虑将数据集分片到多个 Redis 实例（使用 Redis Cluster 或客户端分片）。

总结

Redis 中高 CPU 使用率很少是神秘的；它通常是单线程事件循环因低效命令或过多的后台持久化而过载的症状。通过系统地使用 SLOWLOG，消除 KEYS 等阻塞命令，并调整持久化设置，您可以有效地诊断和解决根本原因，确保您的 Redis 实例保持其特有的高性能。