Redis 核心技术与实战
蒋德钧
中科院计算所副研究员
81696 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 53 讲
开篇词 (1讲)
实践篇 (28讲)
Redis 核心技术与实战
15
15
1.0x
00:00/00:00
登录|注册

19 | 波动的响应延迟:如何应对变慢的Redis?(下)

解决方法
内存大页机制
解决思路
内存swap的影响
解决建议
AOF重写
AOF日志写回策略
分享经验
系统性定位、排查和解决Redis变慢的方法
是否使用了多核CPU或NUMA架构的机器运行Redis实例
是否运行了Redis主从集群
在Redis实例的运行环境中,是否启用了透明大页机制
Redis实例的内存使用是否过大
Redis AOF配置级别是什么
是否存在bigkey
是否对过期key设置了相同的过期时间
是否用了慢查询命令
获取Redis实例在当前环境下的基线性能
操作系统:内存大页
操作系统:swap
文件系统:AOF模式
从Redis的自身命令操作层面排查和解决问题的两种方案
判断Redis变慢的两种方法
文件系统和操作系统
响应延迟和基线性能
每课一问
Checklist
文件系统和操作系统
响应延迟和基线性能
Redis变慢的原因

该思维导图由 AI 生成,仅供参考

你好,我是蒋德钧。
上节课,我介绍了判断 Redis 变慢的两种方法,分别是响应延迟和基线性能。除此之外,我还给你分享了从 Redis 的自身命令操作层面排查和解决问题的两种方案。
但是,如果在排查时,你发现 Redis 没有执行大量的慢查询命令,也没有同时删除大量过期 keys,那么,我们是不是就束手无策了呢?
当然不是!我还有很多“锦囊妙计”,准备在这节课分享给你呢!
如果上节课的方法不管用,那就说明,你要关注影响性能的其他机制了,也就是文件系统和操作系统。
Redis 会持久化保存数据到磁盘,这个过程要依赖文件系统来完成,所以,文件系统将数据写回磁盘的机制,会直接影响到 Redis 持久化的效率。而且,在持久化的过程中,Redis 也还在接收其他请求,持久化的效率高低又会影响到 Redis 处理请求的性能。
另一方面,Redis 是内存数据库,内存操作非常频繁,所以,操作系统的内存机制会直接影响到 Redis 的处理效率。比如说,如果 Redis 的内存不够用了,操作系统会启动 swap 机制,这就会直接拖慢 Redis。
那么,接下来,我再从这两个层面,继续给你介绍,如何进一步解决 Redis 变慢的问题。

文件系统:AOF 模式

你可能会问,Redis 是个内存数据库,为什么它的性能还和文件系统有关呢?
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了导致Redis性能下降的原因及解决方案,从AOF日志的写回策略、操作系统内存swap、内存大页机制等多个维度提出了相应的配置建议和解决思路。针对AOF日志的写回策略和AOF重写对主线程和后台子线程的阻塞情况,提出了相应的配置建议,包括根据业务需求设置appendfsync配置项和考虑使用高速固态硬盘。文章还介绍了如何通过查看Redis进程的swap使用情况来排查性能问题,并提出了增加机器内存或使用Redis集群等解决方法。此外,还提到了避免在生产环境中使用内存大页机制,并提供了相应的操作方法。通过具体的技术细节和案例分析,为读者提供了解决Redis性能问题的实用建议。文章还给出了一个包含9个检查点的Checklist,帮助读者高效地解决Redis性能问题。总之,本文为读者提供了全面的Redis性能优化方案,对于遇到Redis性能问题的读者具有很高的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Redis 核心技术与实战》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(44)

  • 最新
  • 精选
  • Kaito
    关于如何分析、排查、解决Redis变慢问题,我总结的checklist如下: 1、使用复杂度过高的命令(例如SORT/SUION/ZUNIONSTORE/KEYS),或一次查询全量数据(例如LRANGE key 0 N,但N很大) 分析:a) 查看slowlog是否存在这些命令 b) Redis进程CPU使用率是否飙升(聚合运算命令导致) 解决:a) 不使用复杂度过高的命令,或用其他方式代替实现(放在客户端做) b) 数据尽量分批查询(LRANGE key 0 N,建议N<=100,查询全量数据建议使用HSCAN/SSCAN/ZSCAN) 2、操作bigkey 分析:a) slowlog出现很多SET/DELETE变慢命令(bigkey分配内存和释放内存变慢) b) 使用redis-cli -h $host -p $port --bigkeys扫描出很多bigkey 解决:a) 优化业务,避免存储bigkey b) Redis 4.0+可开启lazy-free机制 3、大量key集中过期 分析:a) 业务使用EXPIREAT/PEXPIREAT命令 b) Redis info中的expired_keys指标短期突增 解决:a) 优化业务,过期增加随机时间,把时间打散,减轻删除过期key的压力 b) 运维层面,监控expired_keys指标,有短期突增及时报警排查 4、Redis内存达到maxmemory 分析:a) 实例内存达到maxmemory,且写入量大,淘汰key压力变大 b) Redis info中的evicted_keys指标短期突增 解决:a) 业务层面,根据情况调整淘汰策略(随机比LRU快) b) 运维层面,监控evicted_keys指标,有短期突增及时报警 c) 集群扩容,多个实例减轻淘汰key的压力 5、大量短连接请求 分析:Redis处理大量短连接请求,TCP三次握手和四次挥手也会增加耗时 解决:使用长连接操作Redis 6、生成RDB和AOF重写fork耗时严重 分析:a) Redis变慢只发生在生成RDB和AOF重写期间 b) 实例占用内存越大,fork拷贝内存页表越久 c) Redis info中latest_fork_usec耗时变长 解决:a) 实例尽量小 b) Redis尽量部署在物理机上 c) 优化备份策略(例如低峰期备份) d) 合理配置repl-backlog和slave client-output-buffer-limit,避免主从全量同步 e) 视情况考虑关闭AOF f) 监控latest_fork_usec耗时是否变长 7、AOF使用awalys机制 分析:磁盘IO负载变高 解决:a) 使用everysec机制 b) 丢失数据不敏感的业务不开启AOF 8、使用Swap 分析:a) 所有请求全部开始变慢 b) slowlog大量慢日志 c) 查看Redis进程是否使用到了Swap 解决:a) 增加机器内存 b) 集群扩容 c) Swap使用时监控报警 9、进程绑定CPU不合理 分析:a) Redis进程只绑定一个CPU逻辑核 b) NUMA架构下,网络中断处理程序和Redis进程没有绑定在同一个Socket下 解决:a) Redis进程绑定多个CPU逻辑核 b) 网络中断处理程序和Redis进程绑定在同一个Socket下 10、开启透明大页机制 分析:生成RDB和AOF重写期间,主线程处理写请求耗时变长(拷贝内存副本耗时变长) 解决:关闭透明大页机制 11、网卡负载过高 分析:a) TCP/IP层延迟变大,丢包重传变多 b) 是否存在流量过大的实例占满带宽 解决:a) 机器网络资源监控,负载过高及时报警 b) 提前规划部署策略,访问量大的实例隔离部署 总之,Redis的性能与CPU、内存、网络、磁盘都息息相关,任何一处发生问题,都会影响到Redis的性能。 主要涉及到的包括业务使用层面和运维层面:业务人员需要了解Redis基本的运行原理,使用合理的命令、规避bigke问题和集中过期问题。运维层面需要DBA提前规划好部署策略,预留足够的资源,同时做好监控,这样当发生问题时,能够及时发现并尽快处理。
    2020-09-21
    37
    507
  • ꧁子华宝宝萌萌哒꧂
    echo never /sys/kernel/mm/transparent_hugepage/enabled 这个是不是得改成 echo never > /sys/kernel/mm/transparent_hugepage/enabled 这样?
    2020-09-21
    3
    22
  • 王世艺
    看了下,貌似是这样 redis 有一个aof_buf缓存,用来缓存新的aof操作信息。 正常情况下主线程每次循环都是先将aof_buff write,然后aof_buf是清空, 主线程会用去fsync,已经write的内容。 刷盘当时aways的情况下,主线程去直接调用redis_fsync。 但是当策略是EVERYSEC时,主线程会用aof_background_fsync中的bioCreateBackgroundJob(BIO_AOF_FSYNC,(void*)(long)fd,NULL,NULL);创建子线程去完成。 但是当io压力大的时候,也就是aof_buf有积压是。主线程在EVERYSEC模式下回去判断。是否有aofwrite在执行,并超过2s 如果超过2s主线程不会return,继续将aof_buf write 代码:nwritten = aofWrite(server.aof_fd,server.aof_buf,sdslen(server.aof_buf)); 但是因为子线程在aof_fd上fsync,所以write aof_fd的请求会被堵塞,这里write全是主线程在操作,堵塞直到fsync完成,能改变文件描述符(aof_fd),主线程才可以继续响应请求
    2020-09-23
    5
    18
  • yeek
    如果redis是独立部署,那么当内存不足时,淘汰策略和操作系统的swap机制 哪个会优先执行? 曾遇到过线上触发内存淘汰的场景,并未观察当时的swap情况,感谢老师的建议
    2020-09-21
    4
    10
  • 小可
    redis变慢问题优化自我总结: 1.cpu:redis实例绑定同一个cpu物理核;网络中断和redis实例绑定同一个cpu socket 2.内存:关闭大内存页,观察swap,增加物理内存 3.磁盘:数据丢失容忍度aof策略选择;AOF使用SDD 4.操作:集合操作,bigkey删除,返回集合改为SCAN多次操作 5.过期:过期时间加随机数 6.监控:基线性能--intrinsic-latency; monitor; ;latency
    2021-02-04
    9
  • 花儿少年
    之前出现过redis变慢的问题,导致系统整体变慢,系统大概几小时内30%的请求都很慢,基本到不可用的情况了。 具体情况是某同学(我)在新业务的时候添加了一个新的key,由于符合hash的特性于是直接使用了redission 的map,上线后由于逻辑问题并没有执行到,但是由于仅仅是缓存嘛,业务也没问题,后来由于另外的项目中覆盖到这个case发现有问题,然后就把逻辑修复了。 上线后redis集群的proxy节点的一两个节点cpu使用率飙高,但是没想明白为啥,所以也没回滚,然后第二天中午流量变大了,就会有更多的proxy节点cpu使用率100%,这个时候业务就开始大量报警了,因为接口开始部分超时,然后紧急把那块缓存的代码删除发布上线,然后系统就恢复了。 过程讲完了,接下来说原因,先说下redis集群的架构,流量经过proxy节点分发给redis,业务仅感知到一个vip节点,那么这种情况下,proxy节点就需要对客户端的请求进行保序的操作,这也就是说先到的请求没返回时,后来的请求也不能返回;redisson的map实现是加入了lua脚本的,同时代码里对单个key设置了过期时间,导致整个脚本很复杂很消耗性能,那么redis本身就会变慢,但是不是很明显,同时加上proxy节点,返回到客户端就很慢了,同时加上proxy保序的特点,更加剧了耗时。redis是分片的,所以量小的时只有少部分节点受影响,但是量大时所有的分片上都有这种慢请求,拖慢了整体的性能。。 血泪教训,使用不熟悉的类库时,一定要多看看源码,对公司的产品的特性要熟悉,对隐患要及时止损,想着问题不大也没回滚,简直天真。 不过redisson真的好用。yyds
    2021-07-31
    1
    7
  • aoe
    Redis 变慢?按(老师 + Kaito)一波操作下来不快也得快!
    2021-04-02
    4
  • yeek
    当主线程使用后台子线程执行了一次 fsync,需要再次把新接收的操作记录写回磁盘时,如果主线程发现上一次的 fsync 还没有执行完,那么它就会阻塞。所以,如果后台子线程执行的 fsync 频繁阻塞的话(比如 AOF 重写占用了大量的磁盘 IO 带宽),主线程也会阻塞,导致 Redis 性能变慢。 这段没懂,redis主线程和后台子线程之间有状态通信吗?主线程调用fsync对子线程而言是任务队列的方式还是同步调用的方式? 我去看看源码吧……
    2020-09-21
    5
    4
  • “8. 是否运行了 Redis 主从集群?如果是的话,把主库实例的数据量大小控制在 2~4GB,以免主从复制时,从库因加载大的 RDB 文件而阻塞。” 这个2~4G的经验值和主库的内存大小无关吗?比如主从库内存都是64G, 这个主库数据量依然是2~4G?
    2020-09-21
    1
    3
  • 日落黄昏下
    除了aof重写可能造成堵塞,在aof everysec时,如果发现此时正在进行fsync,并且超过2s时,会堵塞主线程等待。可监控aof-pending-bio-fsync和aof-delay-fsync信息,并且会有aof fsync is taking too long 的日志。
    2021-10-11
    2
收起评论
显示
设置
留言
44
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部