乐趣区

关于后端:Redis内存碎片和Pipeline管道

本文已收录至 Github,举荐浏览 👉 Java 随想录
微信公众号:Java 随想录

内存碎片

内存碎片如何产生的?

Redis 外部有本人的内存分配器,默认是 jemalloc,为了进步内存应用的效率,来对内存的申请和开释进行治理。
而内存分配器依照固定大小分配内存,并不是齐全依照程序申请的内存大小来进行调配。
比方程序申请一个 20 字节的内存,内存分配器会调配一个 32 字节的内存空间,这么做是为了缩小调配次数。redis 会申请不同大小的内存空间来存储不同业务不同类型的数据,因为内存依照固定大小调配且会比理论申请的内存要大一些,这个过程中会产生内存碎片。
举个例子
咱们用高铁车厢阐明,假如一个车厢的座位总共有 60 个,当初曾经卖 了 57 张票,须要三张连在一起的票,但发现买不到了,只好换一趟车。咱们能够把这些扩散的空座位叫作 车厢座位碎片

内存碎片相似下面高铁座位的例子。尽管操作系统的残余空间总量足够,但申请一块间断地址空间 N 字节时,残余内存空间中没有大小为 N 字节的间断空间,那么这些残余空间就是内存碎片。

Redis 的这种机制,进步了内存的使用率,然而会使 Redis 中有局部本人没在用,却不开释的内存,导致了内存碎片的产生。

内存分配器

在编译时指定的 Redis 应用的内存分配器,能够是 libc、jemalloc、tcmalloc,默认是 jemalloc

jemalloc 在 64 位零碎中,将内存空间划分为小、大、微小三个范畴;每个范畴内又划分了许多小的内存块单位;存储数据的时候,会抉择大小最合适的内存块进行存储。

jemalloc 划分的内存单元如下图所示:

也就是说 Redis 是以指定大小的块为单位进行间断内存调配的,而不是按需分配的。Redis 会依据申请的内存最靠近的固定值调配相应大小的空间。

这就像你有不同的箱子,为了装货色,你须要找一个体积最靠近的箱子来装。然而装进去后,你发现还有空间能够放一些小东西,就无需再找箱子了。然而,这种调配空间的形式会带来肯定水平的内存碎片。咱们能够把固定大小的划分空间看成不同体积的箱子,每种箱子里的空间不同水平上都会有残余。这些残余的空间就是内存碎片。

怎么看是否有内存碎片?

咱们登陆到 Redis 服务器上,执行以下命令:

redis> info memory

咱们会看到这些信息:

指标mem_fragmentation_ratio:1.86 示意以后的内存碎片率。

mem_fragmentation_ratio = used_memory_rss / used_memory

used_memory_rss:是 Redis 向操作系统申请的内存。
used_memory:是 Redis 中的数据占用的内存。

所以,mem_fragmentation_ratio= 1 应该是最现实的状况

碎片率的意义?

mem_fragmentation_ratio 的不同值,阐明不同的状况。

  • 大于 1:阐明内存有碎片,个别在 1 到 1.5 之间是失常的。
  • 大于 1.5:阐明内存碎片率比拟大,须要思考是否要进行内存碎片清理,要引起器重。
  • 小于 1:阐明曾经开始应用替换内存,也就是应用硬盘了,失常的内存不够用了,须要思考是否要进行内存的扩容,应用 swap 是相当影响性能的。

清理内存碎片

低于 4.0-RC3 版本的 Redis

如果你的 Redis 版本是 4.0-RC3 以下的,Redis 服务器重启后,Redis 会将没用的内存归还给操作系统,碎片率会降下来。

高于 4.0-RC3 版本的 Redis

Redis4.0-RC3 版本开始,能够在不重启的状况下,线上整顿内存碎片。
主动碎片清理,只有设置了如下的配置,内存就会主动清理了。

redis> config set activedefrag yes 

<font color=OrangeRed> 主动清理内存碎片的性能须要该 Redis 的内存分配器是 jemalloc 时能力启用。</font>

启用后须要同时满足上面 2 个参数的设置条件时才会触发主动清理

active-defrag-ignore-bytes 100mb    # 默认 100MB, 示意内存碎片空间达到 100MB 时
active-defrag-threshold-lower 10    # 默认 10,示意内存碎片空间占 OS 调配给 redis 的物理内存空间的比例达到 10% 时

redis 是单过程模型,内存碎片主动清理是通过主线程操作的,也会耗费肯定的 CPU 资源。为了防止主动清理升高 Redis 的解决性能,如下两个参数能够管制清理动作耗费的 CPU 工夫比例的上上限。

active-defrag-cycle-min 5 : 默认 5,示意主动清理过程所用 CPU 工夫的比例不低于 5%,保障清理能失常发展;active-defrag-cycle-max 75: 默认 75,示意主动清理过程所用 CPU 工夫的比例不高于 75%,一旦超过,就进行清理,从而防止在清理时,大量的内存拷贝阻塞 Redis,导致响应提早升高。

如果你对主动清理的成果不称心,能够应用如下命令,间接试下手动碎片清理:

redis > memory purge

须要留神的是,该清理命令也只当 Redis 的内存分配器是 jemalloc 时能力失效

# 碎片整顿总开关
activedefrag yes
 
#当碎片达到 100mb 时,开启内存碎片整顿
active-defrag-ignore-bytes 100mb
 
#当碎片超过 10% 时,开启内存碎片整顿
active-defrag-threshold-lower 10
 
#内存碎片超过 100%,则尽最大致力整顿
active-defrag-threshold-upper 100
 
#内存主动整顿占用资源最小百分比
active-defrag-cycle-min 5
 
#内存主动整顿占用资源最大百分比
active-defrag-cycle-max 50

Pipeline 管道

为什么须要 Pipeline

Redis 客户端执行一条命令分 4 个过程:

发送命令-〉命令排队-〉命令执行-〉返回后果

这个过程称为 Round Trip Time(简称 RTT, 往返工夫),mget mset 无效节约了 RTT,但大部分命令(如 hgetall,并没有 mhgetall)不反对批量操作,须要耗费 N 次 RTT,这个时候须要 Pipeline 来解决这个问题

Pipeline 模式则是将执行的命令写入到缓冲中,最初由 exec 命令一次性发送给 Redis 执行返回。

1、未应用 Pipeline 执行 N 条命令

2、应用了 Pipeline 执行 N 条命令

原生批命令 (mset, mget) 与 Pipeline 比照

  • 原生批命令是原子性,Pipeline 是非原子性
  • 原生批命令一命令多个 key, 但 Pipeline 反对多命令,Pipeline 不反对事务,因为命令是一条一条执行的。
  • 原生批命令是服务端实现,而 Pipeline 须要服务端与客户端共同完成

Pipeline 的优缺点

  • pipeline 每批打包的命令不能过多,因为 Pipeline 形式打包命令再发送,那么 Redis 必须在解决完所有命令前先缓存起所有命令的处理结果。这样就有一个内存的耗费。
  • Pipeline 操作是非原子性的,如果要求原子性的,不举荐应用 Pipeline
  • 应用 Pipeline 组装的命令个数不能太多,不然数据量过大,减少客户端的等待时间,还可能造成网络阻塞,能够将大量命令的拆分多个小的 pipeline 命令实现。

一些疑难

Pipeline 执行多少命令适合?

依据官网的解释,举荐是以 10k 每批 (留神:这个是一个参考值,请依据本身理论业务状况调整)。

Pipeline 批量执行的时候,是否对 Redis 进行了锁定,导致其余利用无奈再进行读写?

Redis 采纳多路 I / O 复用模型,非阻塞 IO,所以 Pipeline 批量写入的时候,肯定范畴内不影响其余的读操作。

在编码时请留神,Pipeline 期间将“独占”链接,此期间将不能进行非“管道”类型的其余操作,直到 Pipeline 敞开;如果你的 Pipeline 的指令集很宏大,为了不烦扰链接中的其余操作,你能够为 Pipeline 操作新建 Client 链接,让 Pipeline 和其余失常操作拆散在 2 个 client 中。

相干代码

    @Test
    void pipeline() {List<Object> result = redisTemplate.executePipelined((RedisCallback<String>) connection -> {for (int i = 0; i < 100; i++) {redisTemplate.opsForValue().set("pipel:" + i, i);
            }
            return null;
        });
    }

本篇文章就到这里,感激浏览,如果本篇博客有任何谬误和倡议,欢送给我留言斧正。文章继续更新,能够关注公众号第一工夫浏览。

退出移动版