性能文章>Redis OOM(out of memory)内存占用过高,故障分析过程。>

Redis OOM(out of memory)内存占用过高,故障分析过程。原创

https://a.perfma.net/img/2521381
11月前
6087115

本文正在参加「Java应用线上问题排查经验/工具分享」活动

先点赞再看,养成好习惯
背景
全国最大的短信平台,大家都用过我们的产品。数据量比较大,最多时候一天近7亿条短信。
简单介绍一下redis(我们平台用的是codis管理redis集群)
简单来说 redis 就是一个数据库,不过与传统数据库不同的是 redis 的数据是存在内存中的,所以读写速度非常快,因此 redis 被广泛应用于缓存方向。另外,redis 也经常用来做分布式锁。redis 提供了多种数据类型来支持不同的业务场景。除此之外,redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。

回归正题

先看图
image.png
这是2019年8月3日的问题,这个问题导致整个平台半瘫痪3天。平台是8月2日晚上11点版本升级的,然后8月3日,8月4日,8月5日连续半瘫痪3天,才找到问题原因。是该平台迄今为止最大的事故。由于基础不扎实导致排查问题缓慢。

排查思路:

1.发现该问题立马先查redis集群内存使用情况,发现已经达到设置的临界值了。于是迅速调整redis集群内存大小,增大原有内存二分之一,从新启动集群,该问题立马解决,平台趋于稳定运行状态。
2.由于平台的数据量基本是在早上8点到晚上8点之间。周六日的数据量会小于周一到周五的数据量,8月3日大约15点左右平台恢复稳定运行。一直到8月4日早上9点,又开始出现该问题,发现调整后的redis内存依旧不够使用。迅速就调整redis集群的淘汰策略。(1)在内存达到阈值后删除长时间未使用的缓存数据。(2)加入键的时候如果过限,首先从设置了过期时间的键集合中驱逐最久没有使用的键。然后重启集群平台稳定运行。
3.8月5日工作日第一天,短信量增大,原本的淘汰策略已经不好使了。开始 调整应用入redis的数据的过期时间,由原来的24小,调整为半小时,只运行了1个小时。此刻整个平台已经瘫痪,因为redis是必经之路。开始手动清理redis的内存数据。集群状态开始出现问题。原本的3主3从变成4主2从。然后查了4主的IP,有两个IP是相同的,但是无论怎么kill其中一个都杀不掉。迅速就搭建了另外一套redis集群把所有项目的连接全部切到新集群上,业务恢复,但是历史数据丢失。
4.此刻迅速抓包分析(应用到redis之间的数据包)。运维查老集群的进程状态
发现image.png
主进程codis-server 占用12G内存,同步fork 数据进程rdb占用 12G;才导致redis缓存被击穿。抓包分析看到应用和redis交互的数据包中,99%的数据在操作相同的事情(数据格式都一样)。然后查代码分析消息队列去重导致的该问题。立马修改代码恢复业务。

问题解决

1.我们在分配redis集群内存时一定要考虑fork进程占用的数据,他和内存数据占用的内存是相同的。fork进程主要是往硬盘写数据的进程,就是持久化。不要以为服务器内存16G,就直接分配redis内存12个G,这样就不对了。
2.定时去清理过期的缓存,合理规划数据的过期时间。
3.一定要评估当前业务的数据量占用redis的内存空间大小。(这个通过压测可以得到准确数据)
4.备用集群一定要提前准备着以防不时之需。
5.防止内存穿透和雪崩。(具体该方法下期再具体讲)

分类:
标签:
请先登录,再评论

如果再细一点就好咯~

10月前

为你推荐

D炸天的Redis,该如何监控?
本文重点讲述Redis的哪些metrics需要重要监控(篇幅有限,不能涵盖所有),以及我们如何获取这些metrics数据。从而确保对我们应用至关重要的Redis是否健康运行,以及当出现问题时能及时通知
Redis进阶:深入解读阿里云Redis开发规范(修订版)
Key命名设计:可读性、可管理性、简介性规范建议使用冒号即:进行分割拼接,因为很多Redis客户端是根据冒号分类的。比如有几个Key:apps:app:1、apps:app:2和apps:app:3。
构建企业级业务高可用的延时消息中台
业务场景剖析公司业务系统(比如:电商系统)中有大量涉及定时任务的业务场景,例如:实现买卖双方在线沟通的IM系统,为了确保接收方能够收到消息,服务端一般都会有重试策略,即服务端在消息发出的一段时间内,如
Redis client链接池配置不当引起的频繁full gc
现象笔者负责的一个RPC服务就是简单的从Redis Cluster中读取数据,然后返回给上游。理论上该服务的对象大部分都应该是朝生夕死的,但是笔者查看gc log 的时候发现 age =2 的对象还真
记一次线上请求偶尔变慢的排查
前言最近解决了个比较棘手的问题,由于排查过程挺有意思,于是就以此为素材写出了本篇文章。 Bug现场这是一个偶发的性能问题。在每天几百万比交易请求中,平均耗时大约为300ms,但总有那么100多笔会超过
空中楼阁之纸上谈兵 redis中hash的思考
思考点:------与jdk中hashmap的区别?(提示从添加元素、扩容这两个行为开始分析)为什么使用这种添加方式?为什么这样扩容?扩容的时机?具体标准是?是否还有缩容呢?若有,则时机和标准呢?hg
RedLock: 看完这篇文章后请不要有任何疑惑了
后台经常会有小伙伴咨询RedLock相关问题,笔者在此再来一篇文章剖析一下RedLock,希望此文能解决你对它所有的疑惑和误解。 为什么需要RedLock这一点很好理解,因为普通的分布式锁算法在加锁时
Redis OOM(out of memory)内存占用过高,故障分析过程。
本文正在参加「Java应用线上问题排查经验/工具分享」活动先点赞再看,养成好习惯背景全国最大的短信平台,大家都用过我们的产品。数据量比较大,最多时候一天近7亿条短信。简单介绍一下redis(我们平台用