基础信息

  • Redis版本

5.0.6

  • 网络信息
  • 服务器信息 | 角色 | IP | 操作系统 | CPU | 内存 | 磁盘空间 | 顺序读 | 顺序写 | | —- | —- | —- | —- | —- | —- | —- | —- | | redis1 | 10.241.90.2 | CentOS Linux release 7.6.1810 | 4 | 8 | 300G | 238MB/s | 137MB/s | | redis2 | 10.241.90.22 | CentOS Linux release 7.6.1810 | 4 | 8 | 300G | 142MB/s | 126MB/s | | redis3 | 10.241.40.2 | CentOS Linux release 7.6.1810 | 4 | 8 | 300G | 267MB/s | 136MB/s | | 写 | 10.241.40.4 | CentOS Linux release 7.6.1810 | 4 | 8 | 36G | 261 MB/s | 193MB/s | | 读 | 10.241.90.34 | CentOS Linux release 7.6.1810 | 4 | 4 | 36G | 268 MB/s | 188MB/s |

1.读写测试命令如下:

顺序写：

time dd if=/dev/zero of=/data/ddtest bs=1k count=10000000 conv=fdatasync

顺序读：

time dd if=/data/ddtest of=/dev/null bs=1k count=10000000 status=progress

测试场景1

  • 背景
    在对单个key读写情况下，客户端数量对读写性能的影响
  • 案例1
    • 发压命令 
      1. #写命令
      2. redis-benchmark -h 10.241.90.2 -p 7100 -t set -c 10 -n 1000000 -a Bonree@365 --cluster
      3. #读命令
      4. redis-benchmark -h 10.241.90.2 -p 7100 -t get -c 10 -n 1000000 -a Bonree@365 --cluster

  • 测试结果
    | | ip | 写入TPS | 读取TPS | CPU | 内存 | IO | 入流量 | 出流量 | | —- | —- | —- | —- | —- | —- | —- | —- | —- | | reids1 | 10.241.90.2 | 17892.29 | 16792.05 | 26.52 | 3.82 | 0.5 | 962.4K | 585.5K | | redis2 | 10.241.90.22 | 17892.29 | 16792.05 | 34.16 | 3.51 | 0.5 | 1.2M | 722.4K | | redis3 | 110.241.40.2 | 17892.29 | 16792.05 | 35.33 | 3.62 | 0.7 | 904.4K | 546.3K | | 写入 | 10.241.40.4 | | | 58.99 | 9.18 | 0 | 858.4K | 1.5M | | 读取 | 10.241.90.34 | | | 60.16 | 9.81 | | 1.1M | 1.5M |

  • 问题列表
    无

  • 案例总结
    设置客户端数量10，写入TPS为17892.29，读取TPS为16792.05，redis服务端内存占用3%，客户端CPU占用率60%，io无明显消耗。
    • 案例2
  • 发压命令 
    1. #写命令
    2. redis-benchmark -h 10.241.90.2 -p 7100 -t set -c 100 -n 1000000 -a Bonree@365 --cluster
    3. #读命令
    4. redis-benchmark -h 10.241.90.2 -p 7100 -t get -c 100 -n 1000000 -a Bonree@365 --cluster

  • 测试结果
    | | ip | 写入TPS | 读取TPS | CPU | 内存 | IO | 入流量 | 出流量 | | —- | —- | —- | —- | —- | —- | —- | —- | —- | | reids1 | 10.241.90.2 | 98376.78 | 97465 | 49.37 | 3.84 | 0.2 | 4.7M | 2.9M | | reids2 | 10.241.90.22 | 98376.78 | 97465 | 47.16 | 3.58 | 0.40 | 4.7M | 2.9M | | reids3 | 110.241.40.2 | 98376.78 | 97465 | 50.25 | 3.79 | 0.7 | 4.0M | 2.4M | | 写入 | 10.241.40.4 | | | 97.21 | 9.18 | 0 | 5.6M | 9.9M | | 读取 | 10.241.90.34 | | | 97.95 | 9.86 | 0 | 6.0M | 8.7M |

  • 问题列表
    无

  • 案例总结
    设置客户端数量100，写入TPS为98376.78，读取TPS为97465，redis服务端内存占用3%，客户端CPU占用率97%，io无明显消耗。
    • 案例3
  • 发压命令 
    1. #写命令
    2. redis-benchmark -h 10.241.90.2 -p 7100 -t set -c 1000 -n 1000000 -a Bonree@365 --cluster
    3. #读命令
    4. redis-benchmark -h 10.241.90.2 -p 7100 -t get -c 1000 -n 1000000 -a Bonree@365 --cluster

  • 测试结果
    | | ip | 写入TPS | 读取TPS | CPU | 内存 | IO | 入流量 | 出流量 | | —- | —- | —- | —- | —- | —- | —- | —- | —- | | reids1 | 10.241.90.2 | 85295.12 | 80327 | 50.13 | 3.98 | 0.20 | 4.9M | 3.0M | | reids2 | 10.241.90.22 | 85295.12 | 80327 | 50.64 | 3.69 | 0.50 | 3.6M | 2.2M | | reids3 | 110.241.40.2 | 85295.12 | 80327 | 50.13 | 3.79 | 0.7 | 5.9M | 3.8M | | 写入 | 10.241.40.4 | | | 97.21 | 9.22 | 0 | 5.4M | 9.5M | | 读取 | 10.241.90.34 | | | 98.94 | 9.89 | 0 | 5.2M | 7.9M |

  • 问题列表
    无

  • 案例总结
    设置客户端数量100，写入TPS为85295.12，读取TPS为80327，redis服务端内存占用3%，客户端CPU占用率97%，io无明显消耗。
    • 测试结论
  • 案例总结
    | 案例 | 客户端数量 | 写TPS | 读TPS | 服务端内存 | 客户端CPU | 服务端IO | | —- | —- | —- | —- | —- | —- | —- | | 1 | 10 | 17892.29 | 16792.05 | 3% | 60% | 0 | | 2 | 100 | 98376.78 | 97465 | 3% | 97% | 0 | | 3 | 1000 | 85295.12 | 80327 | 3% | 97% | 0 |

查看所有key 

  1. 127.0.0.1:7100> keys *
  2. 1) "key:{06S}:__rand_int__"
  • 案例分析
    通过案例1，案例2，案例3对比可以看到，客户端增加，读写TPS会增加，服务端内存没有太大变化，客户端CPU增加，服务端IO没有明显变化，当客户端CPU到达峰值是，增加服务端数量，读写TPS也不会增加。反而由于客户端抢占CPU资源引起读写TPS降低。服务端每个master实例只保存了一个key。
  • 案例结果
    1、服务端内存消耗由服务端保存key的数量和大小决定
    2、单纯读写redis key不会产生IO性能消耗，因为redis key是保存在内存中
    3、当服务端资源充足的情况下，发压客户端资源也决定读写的性能

测试场景2

  • 背景
  • 案例1
    • 发压命令 
      1. #写命
      2. #-c 客户端大小 
      3. #-n 请求数  
      4. #-d 以字节的形式指定set/get值的数据大小 
      5. #-r 使用随机key
      6. redis-benchmark -t set -h 10.241.90.2 -p 7100 -c 1000 -n 1000000 -r 1000000 -d 45600 -a Bonree@365 --cluster

  • 测试结果
    图一：服务端内存消耗情况
    Redis压测 - 图1
    图二：数据库中key的数量
    Redis压测 - 图2
    图三：key的过期时间 

    1. 127.0.0.1:7100> ttl key:{06S}:000000485090
    2. (integer) -1


    图四：关键参数

  • 问题列表

  • 案例总结
    1、从图一内存消耗情况可以看出，当持续往redis中写入key时，redis服务端内存会持续增加，然后会在2G内存上下波动。
    2、从图一和图二可以看出，当内存快到达redis设置的2G阈值时，会通过删除key来释放内存
    3、从图三和图四可以看出，由于内存策略设置的allkeys-lru（根据 lru 算法，在所有键空间中，移除（最近最少）最久未被使用的key），虽然key没有设置过期时间，但是最久未被使用的key也会被删除
    • 案例2
  • 前提条件
    将内存淘汰策略调整为volatile-lfu
  • 发压命令 
    1. #写命
    2. #-c 客户端大小 
    3. #-n 请求数  
    4. #-d 以字节的形式指定set/get值的数据大小 
    5. #-r 使用随机key
    6. redis-benchmark -t set -h 10.241.90.2 -p 7100 -c 1000 -n 1000000 -r 1000000 -d 45600 -a Bonree@365 --cluster
  • 测试结果
    图一：服务端内存消耗情况
    Redis压测 - 图3
    图二：数据库中key的数量
    Redis压测 - 图4
    图三：写入key
    Redis压测 - 图5
    图四：读取key
    Redis压测 - 图6
  • 问题列表
  • 案例总结
    1、从图一和图二可以看出，当内存到达redis设置的2G阈值时，又没有key被淘汰的情况下，无法再插入新的key，key的数量不会变化
    2、从图三可以看出，当redis内存不足时，再写入key的时候会报内存溢出
    3、从图四可以看出，当redis内存不足时，还是可以读取已经存在的key