redis突然变慢问题定位

已于 2023-07-30 19:36:03 修改
阅读量582 收藏 1
点赞数
CC 4.0 BY-SA版权
文章标签： redis 数据库 缓存
于 2023-07-29 22:04:56 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/myIddddd/article/details/132000691
文章深入探讨了Redis性能下降的原因，包括CPU资源消耗过高、内存管理问题（如bigkey和内存碎片）、数据持久化对磁盘的影响、网络连接负载以及操作系统层面的因素如写时复制和内存配置。提供了从多个维度排查和解决Redis性能问题的思路。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

 

  • CPU 相关：使用复杂度过高命令、O（N）的这个N，数据的持久化，都与耗费过多的 CPU 资源有关

  • 内存相关：bigkey 内存的申请和释放、数据过期、数据淘汰、碎片整理、内存大页、内存写时复制都与内存息息相关

  • 磁盘相关：数据持久化、AOF 刷盘策略，也会受到磁盘的影响

  • 网络相关：短连接、实例流量过载、网络流量过载，也会降低 Redis 性能

  • 计算机系统：CPU 结构、内存分配，都属于最基础的计算机系统知识

  • 操作系统：写时复制、内存大页、Swap、CPU 绑定，都属于操作系统层面的知识

参考文献

Redis为什么变慢了？一文讲透如何排查Redis性能问题 | 万字长文

Redis最佳实践：7个维度+43条使用规范，带你彻底玩转Redis

redis数据结构：快速的Redis有哪些慢操作？
阅读之后，对你有帮助，那就点个赞再走吧
10-12 225
一提到Redis，我们的脑子里马上就会出现一个词：“快。”但是你有没有想过，Redis的快，到底是快在哪里呢？实际上，这里有一个重要的表现：它接收到一个键值对操作后，能以微秒级别的速度找到数据，并快速完成操作。 数据库这么多，为啥Redis能有这么突出的表现呢？一方面，这是因为它是内存数据库，所有操作都在内存上完成，内存的访问速度本身就很快。另一方面，这要归功于它的数据结构。这是因为，键值对是按一定的数据结构来组织的，操作键值对最终就是对数据结构进行增删改查操作，所以高效的数据结构是Redis快速处理数据
Redis：性能风险之定位及解决Redis变慢
张豫湘的博客
04-09 1688
实际的生产环境中不建议开启大页机制，因为redis在fork子进程生成快照以及重写AOF日志时，主线程仍然可以接收写请求，因为采取了写时复制的机制，如果开启了大页机制，则可能对100k的数据进行写操作，此时需要复制一页也就是2MB的内存，且此时会阻塞主进程。**对redis的影响：**当Redis和其他对内存需求大的应用一起运行时，redis是访问内存才能完成，一旦发生swap，redis的请求操作需要等待磁盘的读写操作执行完成才能继续，并且与fsync不同的是，swap影响的是redis的主线程。
Redis为什么变慢了？如何排查Redis性能问题
weixin_42128977的博客
11-01 3060
排除网络原因，如何确认你的 Redis 是否真的变慢了？首先，你需要对Redis进行基准性能测试(什么，你没有做过！！！！)，了解你的 Redis 在生产环境服务器上的基准性能。基准性能就是指Redis在一台负载正常的机器上，其最大的响应延迟和平均响应延迟分别是怎样的？方式一：redis-cli --intrinsic-latency方式二：redis-benchmark你应该也发现了，Redis的性能问题，涉及到的知识点非常广，几乎涵盖了CPU、内存、网络、甚至磁盘。
Redis 突然变慢了如何排查并解决？
sjkflw121150的博客
03-23 741
如下检查清单，帮助你在遇到 Redis 性能变慢的时候能高效解决问题。获取当前 Redis 的基线性能；开启慢指令监控，定位慢指令导致的问题；找到慢指令，使用 scan 的方式；将实例的数据大小控制在 2-4GB，避免主从复制加载过大 RDB 文件而阻塞；禁用内存大页，采用了内存大页，生成 RDB 期间，即使客户端修改的数据只有 50B 的数据，Redis 需要复制 2MB 的大页。当写的指令比较多的时候就会导致大量的拷贝，导致性能变慢。Redis 使用的内存是否过大导致 swap；
redis之变慢了该如何排查？
wang0907的博客
11-17 1319
不管什么工具，会使用永远只是第一步，第二步是当其出现某些问题时，拥有排查和修复问题的能力，而我们在使用Redis的过程中，变慢就是其中一个比较棘手的问题，因此本文就一起来看下，当遇到该类问题时应该如何排查，以求能够在工作中帮助到你，当然也更加是帮助我自己，下面我们就开始吧！1:获取Redis实例在当前环境下的基线性能。2:是否用了慢查询命令？如果是的话，就使用其他命令替代慢查询命令，或者把聚合计算命令放在客户端做。3:是否对过期key设置了相同的过期时间？
Redis 突然变慢了？
l688899886的博客
07-14 895
如下检查清单，帮助你在遇到Redis性能变慢的时候能高效解决问题。获取当前Redis的基线性能;开启慢指令监控，定位慢指令导致的问题;找到慢指令，使用scan的方式;将实例的数据大小控制在2-4GB，避免主从复制加载过大RDB文件而阻塞;禁用内存大页，采用了内存大页，生成RDB期间，即使客户端修改的数据只有50B的数据，Redis需要复制2MB的大页。当写的指令比较多的时候就会导致大量的拷贝，导致性能变慢。Redis使用的内存是否过大导致swap;...
Redis突然变慢问题排查
qq_20004115的博客
04-25 444
Redis作为内存数据库，拥有非常高的性能，单个实例的QPS能够达到10W左右。但我们在使用Redis时，经常时不时会出现访问延迟很大的情况，如果你不知道Redis的内部实现原理，在排查问题时就会一头雾水。 很多时候，Redis出现访问延迟变大，都与我们的使用不当或运维不合理导致的。 这篇文章我们就来分析一下Redis在使用过程中，经常会遇到的延迟问题以及如何定位和分析。 使用复杂度高的命令 如果在使用Redis时，发现访问延迟突然增大，如何进行排查？ 首先，第一步，建议你去查看一下Redis的慢
面试官问：Redis 突然变慢了如何排查？
l688899886的博客
07-15 196
如下检查清单，帮助你在遇到Redis性能变慢的时候能高效解决问题。获取当前Redis的基线性能；开启慢指令监控，定位慢指令导致的问题；找到慢指令，使用scan的方式；将实例的数据大小控制在2-4GB，避免主从复制加载过大RDB文件而阻塞；禁用内存大页，采用了内存大页，生成RDB期间，即使客户端修改的数据只有50B的数据，Redis需要复制2MB的大页。当写的指令比较多的时候就会导致大量的拷贝，导致性能变慢。Redis使用的内存是否过大导致swap；...
lt Redis变慢的原因及排查解决方法
nalanxiaoxiao2011的博客
04-27 1155
redis性能分析
Redis为什么变慢了
zhaoquanwei2018的博客
05-19 369
Redis为什么变慢了？常见延迟问题定位与分析 Redis作为内存数据库，拥有非常高的性能，单个实例的QPS能够达到10W左右。但我们在使用 Redis 时，经常时不时会出现访问延迟很大的情况，如果你不知道 Redis 的内部实现原理，在排查问题时就会一头雾水。 Redis出现访问延迟变大，都与我们的使用不当或运维不合理导致的。 以下这篇文章我们就来分析一下 Redis 在使用过程中，经常会遇到的延迟问题以及如何定位和分析。 文章目录 链路追踪 基准性能 使用了复杂度过高的命令 操作、存储大的big
Redis实战宝典：Redis 突然变慢了如何排查并解决？
无休居士的博客
09-11 881
Redis 性能下降时，首先检查系统资源（CPU、内存、磁盘I/O、网络带宽）是否饱和。使用 `INFO` 命令检查 Redis 服务器状态，关注 `used_memory` 和 `used_memory_rss` 确认内存使用情况。查看 `slowlog` 日志定位慢查询。使用 `TOP` 或 `htop` 监控系统进程，排除外部干扰。优化大键和复杂命令的使用，定期执行 `BGREWRITEAOF` 和 `BGSAVE` 减少磁盘I/O阻塞。确保 Redis 与客户端之间的网络延迟低且稳定。必要时调整配置
Redis为什么变慢了？一文讲透如何排查Redis性能问题
harmful_sheep的博客
07-12 1945
好了，以上就是我总结的在使用 Redis 过程中，常见的可能导致延迟、甚至阻塞的问题场景，以及如何快速定位和分析这些问题，并且针对性地提供了解决方案。这里我也汇总成了思维导图，方便你在排查 Redis 性能问题时，快速地去分析和定位。这里再简单总结一下，Redis 的性能问题，既涉及到了业务开发人员的使用方面，也涉及到了 DBA 的运维方面。
Redis为什么变慢了？一文讲透如何排查Redis性能问题 | 万字长文
Kaito的博客
01-25 466
微信搜索关注「水滴与银弹」公众号，第一时间获取优质技术干货。7年资深后端研发，用简单的方式把技术讲清楚。 Redis 作为优秀的内存数据库，其拥有非常高的性能，单个实例的 OPS 能够达到 10W 左右。但也正因此如此，当我们在使用 Redis 时，如果发现操作延迟变大的情况，就会与我们的预期不符。 你也许或多或少地，也遇到过以下这些场景： 在 Redis 上执行同样的命令，为什么有时响应很快，有时却很慢？ 为什么 Redis 执行 SET、DEL 命令耗时也很久？ 为什么我的 Redis 突然慢了一.
Redis为什么变慢了-常见延迟问题定位与分析
20年码农
02-10 413
以上我们总结了Redis中常见的可能导致延迟增大甚至阻塞的场景，这其中既涉及到了业务的使用问题，也涉及到Redis的运维问题。可见，要想保证Redis高性能的运行，其中涉及到CPU、内存、网络，甚至磁盘的方方面面，其中还包括操作系统的相关特性的使用。作为开发人员，我们需要了解Redis的运行机制，例如各个命令的执行时间复杂度、数据过期策略、数据淘汰策略等，使用合理的命令，并结合业务场景进行优化。作为DBA运维人员，需要了解数据持久化、操作系统fork。
C++实现Gin框架、MySQL、Redis完整指南
keny-大成的博客
07-25 690
《Go语言与Gin框架开发实战指南》 本文摘要全面介绍了使用Go语言Gin框架构建Web应用的多种技术方案，涵盖从基础路由到高级功能的完整开发生态。主要内容包括： 核心开发栈 基于Gin+GORM+MySQL的RESTful API实现方案 Gin与Redis深度集成的12种应用场景 文件上传/静态资源服务的3种处理方式 关键技术点 JWT认证中间件开发流程 WebSocket实时通信实现 GORM事务管理与性能优化 自动API文档生成方案 进阶实践 微服务架构下的Gin应用部署 Docker容器化最佳实践
Redis 5.0终极配置指南
漠然
07-23 844
Redis 5.0配置文件解析与优化指南：摘要 本文详细解析Redis 5.0核心配置文件redis.conf的关键参数，涵盖基础配置、持久化、内存管理、安全设置等模块。重点包括：守护进程模式、RDB/AOF持久化策略、内存淘汰机制、密码认证等安全配置，以及主从复制和集群设置。同时提供性能优化标准，涉及内存压缩、连接管理、持久化调优和数据结构选择等关键技术点，并给出监控指标与维护建议。通过内核参数调优和客户端优化方案，帮助用户实现Redis高性能运行，最后附基准测试方法和不同场景的调优优先级矩阵。
redis7.4.2 启动的操作
NLP与推荐算法
07-23 44
选择 systemd 方式是最可靠的生产环境解决方案，它提供了完善的进程管理、日志收集和故障恢复机制。logfile "/var/log/redis/redis.log" # 日志文件路径。pidfile /var/run/redis.pid # PID 文件路径。sudo systemctl status redis # 检查状态。daemonize yes # 启用守护进程模式。# 安装 screen（如果未安装）# 查看运行中的会话。配置内存和连接数限制。
【Redis】Linux 配置Redis
最新发布
Antonio915的博客
07-26 408
Redis是一款高性能的开源键值数据库，采用内存存储，支持多种数据结构（字符串、哈希、列表等）和持久化功能（RDB/AOF）。具备高可用特性（主从复制、哨兵、集群模式）和原子操作，适用于缓存、会话存储、消息队列等场景。安装配置方面，在Ubuntu系统下载源码编译后，通过修改bind、daemonize等参数调整配置，使用redis-server启动服务，redis-cli连接测试。Redis以其卓越性能（单机QPS 10万+）和丰富功能成为现代应用开发的重要组件。
《整合Spring Cache：本地缓存、Redis与Caffeine对比实践》
qq_43414012的博客
07-25 726
本文深入探讨了Spring Cache的缓存整合实践，对比分析了本地缓存与Redis的优缺点。主要内容包括： Spring Cache核心原理：解析注解驱动机制、源码执行流程和SpEL表达式高级用法，展示缓存Key生成策略。 缓存方案对比：从性能、内存管理、淘汰策略等维度对比Redis/Caffeine/ConcurrentHashMap，提供选型决策树。 Caffeine深度优化：详解其高效淘汰算法，提供配置模板和命中率监控方案，对比其他本地缓存框架。 混合缓存架构：设计多级缓存方案，实现本地+Redis
我们业务目前使用的是阿里云的云资源，关于云资源我配置了如下告警规则，请根据我的告警规则帮我设计一套基于规则的故障检测联合规则 ES-宕机【紧急】 ES-磁盘使用率高 ES-内存使用率高 ES-节点CPU使用率高 ES-集群不健康 ES load 高 kafka-消息堆积 kafka-消息生产量高 kafka-消费量高 kafka-磁盘使用率高 mongodb-磁盘使用率高 mongodb-内存使用率高 mongodb-CPU使用率高 mongodb-连接数高 mongodb-实例重启 mysql-数据库宕机【紧急】 mysql-磁盘使用率高 mysql-内存使用率高【紧急】 mysql-数据库CPU使用率高于70% mysql-IOPS使用率高 mysql-连接池使用率 mysql-行锁时间长 mysql-慢查询过多 mysql-拒绝连接数高 prometheus宕机 redis-内存使用率高 redis-CPU使用率高【紧急】 redis-实例发生重启 redis-连接率高 redis-redis_averager_duration_high redis - 分片CPU使用率高 redis BPS持续高【紧急】 线程池活跃线程数高 线程池队列占用率高 node-宕机【紧急】 node-节点CPU使用率过高 node-节点inode使用率过高 node-节点内存使用率过高 node-节点磁盘使用率过高 节点池CPU request过高 节点池CPU request高于100%【紧急】 节点池CPU Limit高于150% node-节点CPU iowait使用率过高 node-cat-节点内存使用率过高 核心EIP 流入带宽超150MB node 节点starcharge-prod 命名空间下pod超过11个 node 节点starcharge-prod 命名空间下L0应用超过6个 node-新加坡nginx节点CPU使用率过高 coredns 解析超时 Kafka Broker 异常
04-01
<think>嗯，用户需要设计一套基于他们现有告警规则的故障检测联合规则。首先，我需要仔细看看他们配置的告警有哪些。他们用了阿里云，涉及ES、Kafka、MongoDB、MySQL、Redis、Node、线程池、Prometheus、EIP、CoreDNS等多个服务，每个服务都有不同的指标告警，有的标记为紧急。 首先，用户的需求是联合规则，也就是当多个告警同时触发时，能够更准确地判断故障根源。比如，ES宕机是紧急的，可能需要结合磁盘、内存、CPU的告警来判断是否因为资源不足导致的。或者，MySQL的宕机可能和磁盘使用率、IOPS高有关联。所以，联合规则需要考虑不同服务之间的依赖关系和资源竞争情况。 接下来，需要分类处理这些告警。可能分成基础设施层、中间件层、数据库层、应用层等。比如，节点（node）的问题会影响上面运行的Pod和中间件，所以当节点宕机时，可能连带影响ES、Kafka等。这时候需要优先处理节点的问题，再检查其他服务。 然后，标记为紧急的告警需要优先处理。例如，ES-宕机、MySQL-数据库宕机、redis-CPU使用率高紧急、节点池CPU request高于100%紧急等。这些紧急告警可能需要立即响应，甚至自动触发某些恢复操作，比如扩容或重启实例。 另外，有些告警可能存在因果关系。比如，Kafka消息堆积可能是因为生产者消息量突然激增，或者消费者处理能力下降。这时候需要同时监控生产量、消费量和磁盘使用率，判断是源头问题还是处理端的问题。 还需要考虑资源瓶颈的连锁反应。例如，节点磁盘使用率高可能导致Pod被驱逐，进而影响中间件如MySQL或Redis的运行，引发它们的告警。这时候需要从底层资源开始排查。 对于数据库类，比如MySQL，连接数高、慢查询多、行锁时间长可能共同导致数据库响应变慢，甚至宕机。需要将这些关联指标结合起来，分析是否是同一问题导致的多指标异常。 此外，像CoreDNS解析超时可能会影响整个集群的服务发现，导致多个服务无法通信，这时候需要检查CoreDNS本身的资源使用情况，或者网络配置问题。 可能还需要考虑地域因素，比如用户提到的新加坡nginx节点CPU过高，可能需要单独处理，或者检查该区域的流量是否异常，比如EIP流入带宽是否超限。 最后，设计联合规则时，需要设定优先级，紧急告警优先，然后根据依赖关系层层递进。同时，可能需要设置抑制规则，避免重复告警，比如节点宕机导致的其他服务告警可以被抑制，直到节点恢复。 总结来说，联合规则需要从基础设施到应用层，按依赖关系分层，识别关键路径，关联相关指标，设定优先级和抑制策略，确保快速定位根本原因，避免告警风暴，提高故障处理效率。</think>我将基于您列出的告警规则，设计一个分层级联的故障检测联合规则体系，分为三个层级：基础设施层、中间件层、应用层。以下是具体设计方案： 一、基础设施层优先检测（直接影响全局） ------------------------------------- $$ \text{紧急规则} = \text{节点宕机} \vee \text{EIP带宽超限} \vee \text{节点池CPU Request>100\%} $$ 1. **节点宕机联检**： - 当 `node-宕机【紧急】` 触发时 - 立即关联检查： $$ \text{节点存活率} = \frac{\text{存活节点数}}{\text{总节点数}} < 80\% $$ 若成立则触发集群级故障 2. **资源超限联检**： ```python if (节点池CPU Request >100%) or (EIP流入带宽 >150MB): 强制检查对应节点的CPU iowait、磁盘IOPS if 节点磁盘使用率 >85%: 标记为存储瓶颈型故障 ``` 二、中间件层联合检测（服务依赖关系） ----------------------------------- 1. **ES集群故障树**： $$ \text{ES故障} = \text{集群不健康} \wedge (\text{磁盘使用率}>85\% \vee \text{内存}>90\%) $$ - 当 `ES-磁盘使用率高` + `ES load 高` 同时触发时 - 自动检查 JVM 内存压力指标： $$ \text{内存压力指数} = \frac{\text{Young GC次数}}{\text{Old GC次数}} > 10:1 $$ 2. **Kafka消息堆积根因分析**： ``` WHEN (消息堆积量 > 1万条/秒) THEN IF 生产量突增 >300% → 标记为流量激增型故障 ELSE IF 消费量下降 >50% → 检查消费者线程池状态 ELSE IF 磁盘使用率 >90% → 标记为存储瓶颈 ``` 三、数据库层关键路径检测 ----------------------- 1. **MySQL紧急故障矩阵**： | 触发条件 | 关联指标 | 处置策略 | |-------------------------|----------------------------|-----------------------| | 数据库宕机 | 最后5分钟IOPS>基础值200% | 优先恢复主库 | | 行锁时间>30s + 慢查询>50 | 连接池使用率>90% | 触发SQL限流 | 2. **Redis级联检测模型**： $$ \text{Redis危机} = \left(\frac{\text{内存使用率}}{\text{连接率}} > 1.2\right) \wedge \left(\text{分片CPU} > 80\%\right) $$ - 当 `BPS持续高` 触发时 - 自动关联检查： $$ \frac{\text{网络带宽使用量}}{\text{实例规格上限}} > 75\% $$ 四、应用层异常关联规则 --------------------- 1. **线程池雪崩预测**： $$ \text{风险系数} = \left(\frac{\text{活跃线程}}{\text{最大线程}}\right) \times \left(\frac{\text{队列占用率}}{100}\right) > 0.8 $$ - 当风险系数超标时： $$ \text{自动关联检查} = \text{慢查询数量} + \text{Redis响应时间} $$ 2. **Pod密度异常检测**： ``` IF (starcharge-prod Pod数量 >11) THEN 检查: 节点CPU使用率是否>80% 节点内存是否>85% IF 同时触发L0应用>6 → 标记为调度异常 ``` 五、全局抑制规则（避免告警风暴） ------------------------------- 1. 当 `节点宕机` 触发时： - 自动抑制该节点上所有中间件告警（ES/Kafka等） - 抑制时长为故障恢复时间+10分钟 2. 当 `CoreDNS解析超时` 触发时： $$ \text{抑制范围} = \text{所有依赖服务发现的应用告警} $$ 六、推荐配置的响应策略 --------------------- 1. **自动扩容规则**： ``` WHEN (CPU使用率 >85%持续5分钟) AND (节点池CPU Request <90%) AND (非突发流量) THEN 触发节点池自动扩容 ``` 2. **紧急熔断阈值**： | 服务 | 熔断条件 | 动作 | |------------|----------------------------------|--------------------------| | MySQL | 连接拒绝率>30%持续2分钟 | 切断非核心业务连接 | | Redis | 分片CPU>95%持续3分钟 | 启用只读模式 | 建议配合阿里云ARMS服务配置告警流水线，将以上规则划分为： - P0级（需立即人工介入）：红色标记的【紧急】类告警 - P1级（自动处置+通知）：黄色标记的资源类告警 - P2级（仅记录）：蓝色标记的辅助指标告警
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值