redis 问题排查

redis 问题排查

Redis 服务本身问题CPU、Memory、磁盘 IO

1. 内存问题

• used_memory_rss_human：表示目前的内存实际占用——表示当前的内存情况。

• used_memory_peak_human：表示内存峰值占用——表示曾经的内存情况（主要是用来抓不到现场的时候查问题用的）。

• mem_fragmentation_ratio

  • 内存碎片率( mem_fragmentation_ratio )指标给出了操作系统( used_memory_rss )使用的内存与 Redis( used_memory )分配的内存的比率 mem_fragmentation_ratio = used_memory_rss / used_memory 操作系统负责为每个进程分配物理内存，而操作系统中的虚拟内存管理器保管着由内存分配器分配的实际内存映射 那么如果我们的 Redis 实例的内存使用量为1 GB，内存分配器将首先尝试找到一个连续的内存段来存储数据；如果找不到连续的段，则分配器必须将进程的数据分成多个段，从而导致内存开销增加，具体的相关解释可参考这篇文章：Redis 内存碎片的产生与清理 内存碎片率大于1表示正在发生碎片，内存碎片率超过1.5表示碎片过多，Redis 实例消耗了其实际申请的物理内存的150%的内存；另一方面，如果内存碎片率低于1，则表示Redis需要的内存多于系统上的可用内存，这会导致 swap 操作。内存交换到磁盘将导致延迟显著增加 理想情况下，操作系统将在物理内存中分配一个连续的段，Redis 的内存碎片率等于1或略大于1。

• maxmemory

  • 最大内存限制 maxmemory，如果不设这个值，可能导致内存超过了系统可用内存，然后就开始 swap，最终可能导致 OOM。

• maxmemory-policy

  • 内存超过限制后的处理策略，默认是返回一个错误，如果设置为noeviction，则不会返回错误，而是直接丢弃操作。

• evicted_keys

  • 表示由于 maxmemory 策略被驱逐出去的 key 的数量。

• 内存碎片率

  • 内存碎片率低的情况下可能会导致swqp内存。你看，这里其实是内存和磁盘 IO 的联动点。

hotkey 热key

• redis 4.0以上的版本支持了每个节点上的基于LFU的热点key发现机制，使用redis-cli –hotkeys即可，执行redis-cli时加上–hotkeys选项。可以定时在节点中使用该命令来发现对应热点key。

[redis@flink1 bin]$ ./redis-cli -h 127.0.0.1 -p 27001  --hotkeys 

# Scanning the entire keyspace to find hot keys as well as
# average sizes per key type.  You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).

Error: ERR An LFU maxmemory policy is not selected, access frequency not tracked. Please note that when switching between policies at runtime LRU and LFU data will take some time to adjust.

解决 redis hotkey 三板斧

• 如果是多实例的话，就是经典的读写分离！

• 如果是单实例的话，就使用 pipeline 批量写入。

• 如果pipeline无法满足业务的话，就在业务服务只加一层缓存。

查看redis bigkeys 危害

• Redis 阻塞 ：因为 Redis 单线程特性，如果操作某个 bigkey 耗时比较久，则后面的请求会被阻塞。
• 内存空间不均匀 ：比如在 Redis cluster 或者 codis 中，会造成节点的内存使用不均匀。
• 过期时可能阻塞 ：如果 Bigkey 设置了过期时间，当过期后，这个 key 会被删除，假如没有使用 Redis 4.0 的过期异步删除，就会存在阻塞 Redis 的可能性，并且慢查询中查不到（因为这个删除是内部循环事件）。
• 导致倾斜 ：某个实例上正好保存了 bigkey。bigkey 的 value 值很大（String 类型），或者是 bigkey 保存了大量集合元素（集合类型），会导致这个实例的数据量增加，内存资源消耗也相应增加。实例的处理压力就会增大，速度变慢，甚至还可能会引起这个实例的内存资源耗尽，从而崩溃。
• 关联的知识点
  • 内存大页：内存页是用户应用程序向操作系统申请内存的单位，常规的内存页大小是 4KB，而 Linux 内核从 2.6.38 开始，支持了内存大页机制，该机制允许应- 用程序以 2MB 大小为单位，向操作系统申请内存。
  • 由于系统采取的 COW（写时复制）的方案、如果频繁写请求操作的是一个 bigkey，那主进程在拷贝这个 bigkey 内存块时，涉及到的内存大页会更多，时间也会更久，从而延迟比较久。

查看bigkeys

[redis@flink1 bin]$ ./redis-cli -h 127.0.0.1 -p 27001   --bigkeys -i 0.01

# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type.  You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).

[00.00%] Biggest set    found so far 'unactivezuoxiids:2211210001' with 2 members
[00.00%] Biggest zset   found so far 'recentContactsEntList:2108200002:CA43564FEE800002B8441BD0CDA016A1' with 1 members
[00.00%] Biggest zset   found so far 'agentList:499:12345' with 2 members
[00.00%] Biggest hash   found so far '4b7d2590-b17e-470f-8ff5-b690f6537e43' with 1 fields
[00.00%] Biggest hash   found so far 'agentInfo:1049:12345' with 7 fields
[00.00%] Biggest string found so far 'reconnoitre-2307140001-1059-1989-arrest_index' with 5 bytes
[02.29%] Biggest hash   found so far 'agentInfo:1001:2307140001' with 20 fields
[02.29%] Biggest set    found so far 'unactivezuoxiids:2108200002' with 13 members
[02.29%] Biggest hash   found so far 'agentInfo:10001:2108200002' with 21 fields
[04.58%] Biggest hash   found so far 'entInfo:2307140001' with 29 fields
[06.86%] Biggest list   found so far 'skillGroupList:10086' with 2 items
[13.96%] Biggest list   found so far 'skillGroupList:2307140001' with 3 items
[13.96%] Biggest zset   found so far 'agentList:473:2208220001' with 7 members
[16.25%] Biggest hash   found so far 'entInfo:2108200002' with 30 fields
[36.84%] Biggest zset   found so far 'agentList:515:2307140001' with 17 members
[41.42%] Biggest hash   found so far 'zsai:sn' with 76 fields
[55.15%] Biggest list   found so far 'skillGroupList:12345' with 7 items
[57.44%] Biggest list   found so far 'skillGroupList:2208220001' with 11 items
[78.49%] Biggest zset   found so far 'agentList:495:12345' with 45 members

-------- summary -------

Sampled 437 keys in the keyspace!
Total key length in bytes is 13455 (avg len 30.79)

Biggest   list found 'skillGroupList:2208220001' has 11 items
Biggest   hash found 'zsai:sn' has 76 fields
Biggest string found 'reconnoitre-2307140001-1059-1989-arrest_index' has 5 bytes
Biggest    set found 'unactivezuoxiids:2108200002' has 13 members
Biggest   zset found 'agentList:495:12345' has 45 members

20 lists with 43 items (04.58% of keys, avg size 2.15)
305 hashs with 2326 fields (69.79% of keys, avg size 7.63)
8 strings with 24 bytes (01.83% of keys, avg size 3.00)
0 streams with 0 entries (00.00% of keys, avg size 0.00)
13 sets with 56 members (02.97% of keys, avg size 4.31)
91 zsets with 277 members (20.82% of keys, avg size 3.04)

Redis 数据存储的问题key集中过期

• Redis 里面的 key 都会设置过期时间，有可能存在集中过期导致负载过高的问题。

• 过期策略：这个策略是针对设置了过期时间的键（key）进行的。当这些键到达过期时间，Redis会进行删除处理。过期策略主要有以下几种方式：

  • 定时过期：每个设置了过期时间的key都会创建一个定时器，一旦到达过期时间就会立即清除。这种方式可以即时清除过期数据，对内存管理非常友好，但可能会占用大量的CPU资源。
  • 定期删除：Redis会将每个设置了过期时间的key放入到一个独立的字典中，并定期（默认每秒十次，即每100ms一次）遍历这个字典来删除到期的key。这个过程并不是遍历所有设置了过期时间的key，而是采用了一种贪心策略，例如从过期字典中随机抽取一些key，检查并删除其中的已过期key。
  • 惰性删除：在某些情况下，定期删除可能会导致一些已经过期的key并没有被删除。惰性删除就是在客户端尝试获取一个已经过期的key时，Redis会主动删除这个key，确保获取操作一定不会得到过期的数据。

• 驱逐策略：这是当Redis的内存使用达到上限时触发的。Redis会使用一系列算法来决定要删除哪些key，以便为新数据腾出空间。驱逐策略有以下几种方式：

  • noeviction：不进行驱逐，拒绝写入新数据并返回错误信息。
  • allkeys-lru：从所有key中挑选最近最少使用的key进行删除。
  • volatile-lru：从设置了过期时间的key中挑选最近最少使用的key进行删除。
  • allkeys-random：从所有key中任意选择key进行删除。
  • volatile-random：从设置了过期时间的key中任意选择key进行删除。
  • volatile-ttl：从设置了过期时间的key中挑选剩余存活时间最短的key进行删除。

Redis 数据存储的问题——key 的总数

• info keyspace
  • 单实例建议控制在 1kw内；单实例键个数过大，可能导致过期键的回收不及时。