redis性能问题排查学习笔记

目录

1. redis服务器基准性能测试

2. 判断redis是否真的变慢

3. redis变慢原因分析

(1) 使用复杂度过高的命令

(2) 操作bigkey

（3）集中过期

（4）实例内存达到上限

（5）fork耗时严重

（6）开启AOF

（7）绑定CPU

（8）使用Swap

（9）碎片整理

（10）网络带宽过载

（11）其他原因

总结：

---

本问是在阅读学习公众号水滴与银弹的文章《Redis为什么变慢了？一文讲透如何排查Redis性能问题 | 万字长文》之后，记录下自己的学习笔记（截图转自该文章，仅用作自己学习）

1. redis服务器基准性能测试

// 这个实例60秒内的最大响应延迟
redis-cli -h 127.0.0.1 -p 6379 --intrinsic-latency 60
// 查看一段时间内 Redis 的最小、最大、平均访问延迟
redis-cli -h 127.0.0.1 -p 6379 --latency-history -i 1

2. 判断redis是否真的变慢

• 在相同配置的服务器上，测试一个正常 Redis 实例的基准性能
• 找到你认为可能变慢的 Redis 实例，测试这个实例的基准性能
• 如果你观察到，这个实例的运行延迟是正常 Redis 基准性能的 2 倍以上，即可认为这个 Redis 实例确实变慢了

3. redis变慢原因分析

(1) 使用复杂度过高的命令

1. 设置满日志的阈值

# 命令执行耗时超过 5 毫秒，记录慢日志 
CONFIG SET slowlog-log-slower-than 5000 
# 只保留最近 500 条慢日志
CONFIG SET slowlog-max-len 500

 

2. 执行 slowlog get n查看最近记录的满日志

3. 较为复杂的命令

• 经常使用 O(N) 以上复杂度的命令，例如 SORT、SUNION、ZUNIONSTORE 聚合类命令
• 使用 O(N) 复杂度的命令，但 N 的值非常大

4. 优化方案

• 1. 尽量不使用复杂度过高的命令，对于数据聚合操作，放在客户端操作
• 2. 执行O(N)命令，保证n尽量小（推荐300以下）

(2) 操作bigkey

1. 扫描bigkey的命令

redis-cli -h 127.0.0.1 -p 6379 --bigkeys -i 0.01

...
-------- summary -------

Sampled 829675 keys in the keyspace!
Total key length in bytes is 10059825 (avg len 12.13)

Biggest string found 'key:291880' has 10 bytes
Biggest   list found 'mylist:004' has 40 items
Biggest    set found 'myset:2386' has 38 members
Biggest   hash found 'myhash:3574' has 37 fields
Biggest   zset found 'myzset:2704' has 42 members

36313 strings with 363130 bytes (04.38% of keys, avg size 10.00)
787393 lists with 896540 items (94.90% of keys, avg size 1.14)
1994 sets with 40052 members (00.24% of keys, avg size 20.09)
1990 hashs with 39632 fields (00.24% of keys, avg size 19.92)
1985 zsets with 39750 members (00.24% of keys, avg size 20.03)

 

2. 注意：

• 对线上实例进行 bigkey 扫描时，Redis 的 OPS 会突增，为了降低扫描过程中对 Redis 的影响，最好控制一下扫描的频率，指定 -i 参数即可，它表示扫描过程中每次扫描后休息的时间间隔，单位是秒
• 扫描结果中，对于容器类型（List、Hash、Set、ZSet）的 key，只能扫描出元素最多的 key。但一个 key 的元素多，不一定表示占用内存也多，你还需要根据业务情况，进一步评估内存占用情况

3. 优化方案：

• 业务应用尽量避免写入 bigkey
• 如果你使用的 Redis 是 4.0 以上版本，用 UNLINK 命令替代 DEL，此命令可以把释放 key 内存的操作（对于比较大的key，释放内存时同样会很耗时），放到后台线程中去执行，从而降低对 Redis 的影响
• 如果你使用的 Redis 是 6.0 以上