Redis 性能优化 —— 内存碎片_redis 内存碎片

一、内存碎片场景描述

• 作为内存数据库，内存空间的大小对于 Redis 来说是至关重要的。内存越多意味着存储的数据也会越多，内存利用率的高低直接关系到 Redis 运行效率的高低

• 在实际研发过程中发现，明明物理内存很大，但是实际的内存使用却不是很理想（删除了 Redis 数据后，采用 top 命令还是可以看到 Redis 占用的内存很多）

• 那么这些删除的数据为什么没有按照预期释放 Redis 的内存呢？这是因为，当数据删除后，Redis 释放的内存空间会由内存分配器管理，并不会立即返回给操作系统。所以，操作系统仍然会记录着给 Redis 分配了大量内存。具体分析请继续往下看。

二、内存碎片概念解析

1. 内存碎片的定义：

   • 根据操作系统的架构和 Redis jemalloc 分配策略，应用程序申请内存大小必须是一块连续的内存地址空间的 N 个字节（N 表示需要向物理内存申请大于等于实际需要存储数据的内存空间的大小）

   • 虽然操作系统的剩余内存空间足够，但是应用程序申请的是一块连续的地址空间的 N 个字节，而实际已申请的剩余的内存空间中没有大小为 N 字节的连续空间，导致这块剩余空间不可用，那么这些剩余空间对于内存整体来说就是内存碎片

2. 内存碎片的理解

   • 假设操作系统为你分配了 32 字节的连续内存空间，而你实际业务存储数据的时候只需要 24 字节内存空间

   • 在下一次存储数据时，实际数据需要 10 字节的内存，刚刚申请剩下的 8 字节内存无法保存 10 字节的数据，应用程序不得不重新向操作系统再次申请 16 字节的连续空间来存储 10 字节的数据

   • 那么多余的 8 字节内存空间以及第二次申请所剩的 6 字节的内存空间，如果后续没有办法被分配存储其它数据，那么这些剩余的内存空间就是内存碎片

3. 内存碎片的类比

   • 应用程序 A 需要保存 6 字节的数据，jemalloc 按分配策略向物理内存申请 8 字节的连续空间，如果应用程序 A 不再保存新数据，那么这多出来的 2 字节空间就是内存碎片

     

   • 应用程序 A 需要再保存 6 字节的数据，由于上面申请的内存只有 2 字节的连续空间，不够保存 6 字节的数据，所以 jemalloc 按分配策略向物理内存又申请了 8 字节的连续空间

     

三、内存碎片产生原因

• 根据上一步对 jemalloc 内存分配策略的特性以及实际案例的理解，导致内存碎片形成有内因和外因两个层面的原因。简单来说，内因就是操作系统的内存分配机制，外因就是 Redis 的存储特性。

• 内因：内存分配器的分配策略

  • 内存分配器的分配策略就决定了操作系统无法做到“按需分配”

  • 内存分配策略一般都是按固定大小来分配内存，而不是完全按照应用程序申请的内存大小来给程序分配内存

  • Redis 的分配器包括：libc、jemalloc、tcmalloc 多种内存分配器来分配内存，默认使用的是 jemalloc 内存分配器

  • 以 jemalloc 分配策略为例（其它的内存分配策略也存在类似问题）：jemalloc 的分配策略之一是按照一系列固定大小划分内存空间，例如：8字节、16 字节、32 字节、64 字节、…2KB、4KB、8KB等。当程序申请的内存最接近某个固定值时， jemalloc 会给它分配相应的大小的空间。这样的分配方式本身是为了减少分配次数（如：应用程序需要申请 24 字节的内存，那么 jemalloc 会取最近的 32 字节的连续内存空间分配给应用程序）。

  • 但是，如果 Redis 每次向分配器申请的内存空间大小不一样，这种分配方式就会有形成碎片的风险，而这正好来源于 Redis 的外因了

• 外因：Redis 键值对大小不一致和更新操作

  • Redis 通常作为公用的缓存系统或者键值数据库对外提供服务，不同的业务应用的数据都可以保存在 Redis 中，这就会带来不同大小的键值对。这样一来，Redis 申请内存空间分配时，本身就会有大小不一的空间需求

  • 上面也说到，内存分配器只能按照固定大小分配内存，所以，分配的内存空间一般都会比申请的空间大一些，不会完全一致，这本身就会造成一定的碎片，降低内存空间存储效率，这就是第一个外因

  • 应用程序对键值对的修改和删除，也会导致空间的扩容和释放，一方面，如果修改后的键值对变大或者变小了，就需要占用额外的空间或者释放不用的空间。另一方面，删除的键值对就不再需要内存空间了，此时，就会把空间释放出来，形成空间剩余或者空闲

  

  1. 应用 A、B、C、D 分别保存了 3、1、2、2 字节的数据，并占据了相应的内存空间。

  2. 应用 D 删除了 2 字节，这块连续空间剩余 2 字节内存碎片

  3. 应用 A 修改为 4 字节，由于空间不连续，操作系统将应用 B 的数据拷贝到了别的空间，最后剩余 1 字节内存碎片

四、内存碎片如何判断

• Redis 查看内存使用细节 —— info memory

  [root@localhost ~]# /opt/redis-6.0.9/src/redis-cli -h 192.169.5.107 -p 7003
  192.169.5.107:7003> auth ******
  OK
  192.169.5.107:7003> info memory
  # Memory
  used_memory:254075496
  used_memory_human:242.31M
  used_memory_rss:381378560
  used_memory_rss_human:363.71M
  used_memory_peak:2939252680
  used_memory_peak_human:2.74G
  used_memory_peak_perc:8.64%
  used_memory_overhead:34808840
  used_memory_startup:1475344
  used_memory_dataset:219266656
  used_memory_dataset_perc:86.80%
  allocator_allocated:254256784
  allocator_active:325685248
  allocator_resident:384983040
  total_system_memory:16647553024
  total_system_memory_human:15.50G
  used_memory_lua:109568
  used_memory_lua_human:107.00K
  used_memory_scripts:1440
  used_memory_scripts_human:1.41K
  number_of_cached_scripts:4
  maxmemory:10737418240
  maxmemory_human:10.00G
  maxmemory_policy:noeviction
  allocator_frag_ratio:1.28
  allocator_frag_bytes:71428464
  allocator_rss_ratio:1.18
  allocator_rss_bytes:59297792
  rss_overhead_ratio:0.99
  rss_overhead_bytes:-3604480
  mem_fragmentation_ratio:1.50
  mem_fragmentation_bytes:127344080
  mem_not_counted_for_evict:2122
  mem_replication_backlog:1048576
  mem_clients_slaves:0
  mem_clients_normal:266552
  mem_aof_buffer:2560
  mem_allocator:jemalloc-5.1.0
  active_defrag_running:0
  lazyfree_pending_objects:0
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  33
  34
  35
  36
  37
  38
  39
  40
  41
  42
  43
  44
  45

• Redis 重要内存参数解读

  • used_memory：Redis 已使用的内存大小，单位 Byte
  • used_memory_human：Redis 已使用的内存大小，单位 Mb
  • used_memory_rss：操作系统实际分配给 Redis 的物理内存空间，单位 Byte
  • used_memory_rss_human：操作系统实际分配给 Redis 的物理内存空间，单位 Mb
  • mem_fragmentation_ratio：Redis 当前的碎片率（减去 1 表示内存碎片比例）
  • mem_fragmentation_bytes：Redis 当前的碎片大小，单位 Byte

• Redis 重要内存参数关系

  • 内存碎片率的计算公式

    内存碎片率 = 已分配的内存 / 实际使用的内存
    mem_fragmentation_ratio = used_memory_rss / used_memory
    1
    2

  • 1 < mem_fragmentation_ratio <= 1.5 经验值一般保持在 1~1.5 之间是最合理的，这是因为，刚才我们介绍的那些因素是难以避免的，毕竟，内因的内存分配器是一定要使用的，分配器策略是通用的不会轻易修改。而外因是由 Redis 存储策略决定，也无法限制，所有存在内存碎片也是正常的情况（内存碎片率值越大代表内存碎片率越严重）

    # 按照当前的信息，内存碎片率是 1.5 - 1 = 0.5（50%）
    used_memory:254075496 -> 242.31M
    used_memory_rss:381378560 -> 363.71M
    mem_fragmentation_ratio:1.50
    mem_fragmentation_bytes:127344080 -> 121.44M
    1
    2
    3
    4
    5

  • mem_fragmentation_ratio > 1.5 这表明内存碎片率已经超过了 50% 。一般情况下，这个时候就应该采取一些措施来降低内存碎片率了

五、内存碎片解决方案

• Redis 内存碎片虽然不会影响 Redis 性能，但是会增加内存消耗，导致不必要的内存浪费，导致 Redis 的内存实际利用率变低

• 快速查看内存碎片率

  redis-cli -c -h 192.169.5.107 -p 7001 -a '******' info memory | grep mem_fragmentation_ratio
  1

• 解决方案一：推倒重来

  • 该方案是最简单的方式，直接推倒重来。也就是把 Redis 直接重启就完事儿了，内存一断电全世界就清净。但是这种最暴力省事的方式却有很多隐患

  • 生产环境这么搞，如果你没有进行过持久化，数据就会丢失。如果有持久化的话，我们还需要通过 AOF 或者 RDB 文件进行数据恢复，那么恢复时长就得取决于你持久化文件的大小，在这个阶段 Redis 是无法对外提供服务的

• 解决方案二：空间置换（搬家让位、合并空间）

  • 为避免内存碎片率过大的问题，Redis 4.0-RC3 版本开始支持自动整理 Redis 内存碎片

  • 查看 Redis 是否已经开启自动碎片整理机制

    [root@localhost ~]# redis-cli -c -h 192.169.5.107 -p 7001 -a '******'
    192.169.5.107:7001> config get activedefrag
    1) "activedefrag"
    2) "no"
    192.169.5.107:7001> 
    1
    2
    3
    4
    5

  • 解析 Redis 内存碎片自动整理机制

    • 开启内存碎片清理

      # 开启或关闭自动内存碎片整理机制
      config set activedefrag yes
      1
      2

    • 以下条件满足任意一个就会触发内存碎片清理

      # 内存碎片占用空间达到 500mb 的时候开始清理
      config set active-defrag-ignore-bytes 500mb
      
      # 内存碎片率大于 1.5（50%）的时候开始清理
      config set active-defrag-threshold-lower 50
      
      # 内存碎片率大于 2（100%） 的时候尽最大清理
      config set active-defrag-threshold-upper 100
      1
      2
      3
      4
      5
      6
      7
      8

    • Redis 自动内存碎片整理机制可能会对 Redis 的性能产生影响，在处理的过程中，操作系统需要把多份数据拷贝到新位置，把原有空间释放出来，这会带来时间开销。因为 Redis 是单线程，在数据拷贝时，Redis 只能等着，这就导致 Redis 无法及时处理请求，性能就会降低。而且，有的时候，数据拷贝还需要注意顺序，这种对顺序性的要求，会进一步增加 Redis 的等待时间，导致性能降低。为了避免对正常请求的影响，同时又能保证性能。自动内存碎片清理功能在执行时，还会监控清理操作占用的 CPU 时间，而且还设置了两个参数，分别用于控制清理操作占用的 CPU 时间比例的上、下限，既保证清理工作能正常进行，又避免了降低 Redis 性能。

      # 内存碎片清理所占用 CPU 时间的比例不低于 20%，保证清理能正常开展
      config set active-defrag-cycle-min 20
      
      # 内存碎片清理所占用 CPU 时间的比例不高于 50%，一旦超过则停止清理，从而避免在清理时，大量的内存拷贝阻塞 Redis，导致其它请求延迟
      config set active-defrag-cycle-max 50
      1
      2
      3
      4
      5

    P.S

    • 如果采用的是高可用的 Redis 集群架构的话，也可以将碎片率过高的主节点切换为从节点，以便进行安全重启

    • 内存碎片自动清理涉及内存拷贝，这对 Redis 而言，是个潜在的风险。如果在实践过程中遇到 Redis 性能变慢，记得通过日志看下是否正在进行碎片清理。如果 Redis 的确正在清理碎片，那么，建议你调小 active-defrag-cycle-max 的值，以减轻对正常请求处理的影响。

    • Redis 在进行内存碎片整理时，由于是主线程操作的，所以这块也是一个影响 Redis 性能的风险点

  • 开启 Redis 内存碎片自动整理机制

    # 1、登录 Redis 集群
    redis-cli -c -h 192.169.5.107 -p 7001 -a '******'
    
    # 2、查看内存碎片自动整理机制是否开启（默认关闭）
    192.169.5.107:7001> config get activedefrag
    1) "activedefrag"
    2) "no"
    
    # 3、开启 Redis 自动内存碎片整理机制
    192.169.5.107:7001> config set activedefrag yes
    OK
    
    # 4、设置内存碎片清理所占用 CPU 时间的比例不高于 75%
    192.169.5.107:7001> config set active-defrag-cycle-max 75
    OK
    
    # 5、设置内存碎片清理所占用 CPU 时间的比例不低于 25%
    192.169.5.107:7001> config set active-defrag-cycle-min 25
    OK
    
    # 6、设置启动活动碎片整理的最小碎片百分比，内存碎片率大于 0.05 的时候开始清理
    192.169.5.107:7001> config set active-defrag-threshold-lower 5
    OK
    
    # 7、设置内存碎片超过 100%，尽最大清理
    192.169.5.107:7001> config set active-defrag-threshold-upper 100
    OK
    
    # 8、设置内存碎片的字节数达到256M时开始清
    192.169.5.107:7001> config set active-defrag-ignore-bytes 268435456
    OK
    
    # 9、写入配置
    192.169.5.107:7001> config rewrite
    OK
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35

六、内存碎片扩展技能

1. 手动清理内存碎片

   memory purge
   1

2. 内存分配情况内部统计报表

   memory malloc-stats
   1