本文主要是介绍Redis变慢?深入浅出Redis性能诊断系列文章(三),对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
(本文首发于“数据库架构师”公号,订阅“数据库架构师”公号,一起学习数据库技术,助力职业发展)
本篇为Redis性能问题诊断系列的第三篇,主要从Redis服务层面上进行讲解,重点对相关机制的工作原理进行剖析,及如何最优的使用来提高处理性能。
![](/upload/202209/15/202209150218484838.png)
一.数据持久化的影响
为了保证 Redis 数据的安全性,我们可能会开启Redis的持久化将数据落盘,避免Redis服务崩溃或者服务器宕机导致的数据丢失。
Redis当前支持两种典型的持久化模式:RDB、AOF。
- RDB持久化,称为内存快照。这种模式是把当前Redis服务的内存数据在某一点dump生成快照保存到磁盘上的过程,由于是某一时刻的快照,开启快照后发起后所有操作命令都不会再被记录。
- AOF 持久化。AOF持久化以日志的形式记录Redis所执行的每个写操作,注意查询操作不会记录,可以打开磁盘文件看到每条详细的操作记录。
关于Redis持久化这里不做过多详细介绍,大家需要记住开启持久化后会对Redis的访问性能带来影响就行,后面会专文讲解两种持久化模式的细节。本文主要对持久化影响Redis访问响应进行分析说明。
1.RDB镜像落盘及AOF重写时的影响
Redis开始执行RDB或者AOF Rewrite后,主进程都会创建出一个子进程进行数据的持久化落盘操作。在这个过程中,则会调用操作系统的 fork 操作。
通过 fork 对内存数据的 copy-On-Write 机制最廉价的实现内存镜像。虽然内存是 copy on write 的,但是虚拟内存表是在 fork 的瞬间就需要分配,所以这个操作会造成主线程短时间的卡顿(停止所有读写操作),这个卡顿时间和当前 Redis 的内存使用量有关。
根据经验 GB 量级的 Redis 进行 fork 操作的时间在毫秒级。
如果这个Redis实例很大,CPU负载再高些,那么 fork 的耗时就会更长,甚至达到秒级,也就会严重影响 Redis 的访问响应时间。
这时反映到业务层面表现就是仿佛Redis服务有一瞬间卡主了,所有的请求不再快速返回,大量的超时出现,然后一会突然又好了。
# 相关监控指标上一次fork操作耗时,单位微秒
redis> info stats
。。
latest_fork_usec:67412
可以添加一个监控,如果发现这个耗时过长且频繁出现,就需要警惕了。
为了避免这种情况,可以采取以下优化方式:
- 关闭RDB和AOF的自动触发机器,避免业务高峰自动触发执行;
- 控制 Redis 使用内存大小,建议控制在20G 以下,因为执行 fork 的耗时与数据内存大小有关,数据越多,耗时会越久;
- 对于主从集群架构,建议关闭主库AOF,从库开启;对于有备份需求的集群,也可以在从库发起RDB备份操作;
- 合理配置 repl-backlog-size大小,降低主从全量重传【2.8版本之前的节点强烈建议升级】;
- 尽量不要使用虚拟机,fork 的耗时也与系统也有关,虚拟机比物理机耗时更长。
2.AOF持久化磁盘IO带来的影响
前文主要介绍了两种持久化过程中Fork操作对性能的影响,现在主要说下AOF持久化开启后对性能的影响。
关于AOF持久化刷盘的三种策略【no/everysec/always】,这里不过多讲解,大家可以自行查阅资料。
当 Redis 开启 AOF持久化 后,两个主要动作:
- Redis 接收写命令后,把命令写入 AOF 文件缓冲区中(AOF write)
- 根据AOF 刷盘策略【everysec/always】,把 AOF 缓冲数据刷到磁盘上(AOF fsync)
AOF 持久化最耗时的刷盘操作,都是在后台线程执行的,但为什么也会影响到 Redis 主线程处理请求呢?
这里需要分析下AOF执行文件持久化刷新时的流程:
![](/upload/202209/15/202209150218489086.png)
具体处理流程:
- 数据写入请求来后,主线程写入AOF缓冲区;
- AOF fsync后台线程每秒一次执行磁盘文件刷入操作,并记录最近一次同步时间;
- 主线程对比AOF同步时间:
- 如果距离上次fsync同步时间在两秒内,主线程继续进行写入
- 如果距离上次fsync同步时间超过两秒(比如磁盘的 IO 负载很高导致同步写磁盘很慢,还在持续写入没有结束),主线程将会被阻塞, 直到同步完成。
如果fsync过慢,这时系统日志中会有如下提示信息:
Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.
Redis自身也提供了相关的性能指标:
redis>info Persistence
。。
aof_delayed_fsync:2
如果aof_delayed_fsync一直在增加,说明主线程频繁出现被阻塞情况,那么就需要关注是否持久化过慢造成Redis访问变慢了。
针对AOF持久化对Redis性能可能带来的影响可以参考如下几种解决方案:
- SSD 磁盘存储,确保AOF刷盘时有充足的IO能力
- 对于主从集群架构,建议关闭主库AOF,从库开启
- 将no-appendfsync-on-rewrite参数设置为yes, 确保aof文件rewrite期间不做fsync操作,减少IO争用
- 单台服务器不要部署过多持久化实例节点,避免磁盘IO争抢带来持久化压力
二、内存碎片过大及整理带来的性能损耗
Redis 的所有数据都在内存中,当应用频繁修改时,就会导致产生内存碎片。过高的内存碎片率,不仅会浪费内存资源还会影响请求处理的效率。
那么,是什么原因导致Redis 产生碎片的呢?原理是什么,能避免吗?
当前Redis 都默认使用jemalloc内存分配器来分配内存,它一般是按固定大小来分配内存空间,而不会按照应用程序申请的内存大小给实际分配。当程序申请的内存大小最接近某个固定值时,如8 byte、16 byte,…,2KB、4KB 等,jemalloc 会给它分配相应大小的空间。
这样的方式好处是为了减少分配次数。假设Redis申请一个 10 byte的内存空间存储数据,jemalloc 会分配 16 byte,此时,如果应用还要再写入 4 byte的数据,Redis 就不用再向操作系统申请空间了,因为刚才分配的 16 byte已经够用了,也就避免了一次额外分配操作开销。
所以Redis每次分配的内存空间一般都会比申请的实际需求空间大一些,这种分配方式就自然会导致形成碎片。
从目前Redis内存的分配机制来看,目前碎片无法完全避免。
Redis 的内存利用率的高低除了成本外,也会直接影响到 Redis 运行效率的高低。可以使用如下命令查看Redis内存使用、碎片率、分配器版本等详细信息:
redis> info Memory
used_memory:6617819416
used_memory_human:6.16G
used_memory_rss:9788588032
used_memory_rss_human:9.12G
...
rss_overhead_ratio:1.00
rss_overhead_bytes:-21159936
mem_fragmentation_ratio:1.48
mem_fragmentation_bytes: 3250855264
...
mem_allocator:jemalloc-5.1.0
...
mem_fragmentation_ratio 就是Redis 当前的内存碎片率大小,碎片率计算方法:
mem_fragmentation_ratio=used_memory_rss/used_memory
used_memory 表示存储的数据实际占用内存的大小,而used_memory_rss 指操作系统分配给 Redis进程服务的实际大小,也就是使用top命令查看Redis进程占用的内存。
一般当mem_fragmentation_ratio>1.5时,就说明内存碎片率已经超过了50%,此时建议采取措施来降低内存碎片大小。
如何清理内存碎片呢?根据版本的不同有两种方式:
- Redis 4.0 以前的低版本,只能通过重启实例来解决,不能自动配置回收
- 从 4.0版本以后,提供了一种内存碎片自动回收的方法,可以通过配置动态开启碎片整理
但要注意:开启内存碎片整理,会导致 Redis 服务性能下降。
Redis 的碎片整理工作是在主线程中执行的,当其进行碎片整理时,操作系统会把多份数据拷贝到新位置以把原有空间释放出来,这会带来时间开销,而这个过程就会阻塞Redis处理请求。
为了降低碎片整理带来的性能影响,Redis 为自动内存碎片整理功机制提供了多个参数,具体有:
activedefrag yes #是否开启碎片整理
active-defrag-ignore-bytes 500mb #碎片大小超过 500MB 时才会触发整理
active-defrag-threshold-lower 20 #碎片大小占操作系统分配总空间比超过 20% 时触发整理
active-defrag-cycle-min 15 #碎片整理过程占用的CPU比例不低于 15%,保证整理可以正常执行
active-defrag-cycle-max 70 #碎片整理过程占用的CPU比例不高于70%,一旦超过就暂停整理,避免大量的内存拷贝等整理过程占用过多的CPU进而影响正常请求
active-defrag-max-scan-fields 500 #碎片整理过程中,对于 Hash、List、Set、ZSet 等成员集合类型一次扫描的元素数量
在开启碎片自动整理时,一定要优先评估当前 Redis 服务的负载状态,以及应用程序可接受的响应延迟,合理设置碎片整理的参数值和回收时间段【比如放到凌晨程序定时触发】,来尽可能降低碎片整理期间对Redis服务的影响。
![](/upload/202209/15/202209150218491132.png)
如果这篇文章对你有收获,还请帮忙点赞、在看、转发 一下,您的支持会激励我们输出更多高质量的文章,非常感谢!
如果你还想看更多优质文章,欢迎关注公号「数据库架构师」或扫描我的二维码,添加个人微信,技术交流、围观朋友圈,一起学习和成长
这篇关于Redis变慢?深入浅出Redis性能诊断系列文章(三)的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!