Redis系列之(四)——深入reids优化

字数 1354阅读 946

一、redis内存

1、内存占用

info memory

info memory

127.0.0.1:6379> info memory
# Memory
used_memory:940008
used_memory_human:917.98K
used_memory_rss:1540096
used_memory_rss_human:1.47M
used_memory_peak:940008
used_memory_peak_human:917.98K
used_memory_peak_perc:100.01%
used_memory_overhead:936014
used_memory_startup:835330
used_memory_dataset:3994
used_memory_dataset_perc:3.82%
total_system_memory:1911857152
total_system_memory_human:1.78G
used_memory_lua:37888
used_memory_lua_human:37.00K
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
mem_fragmentation_ratio:1.64
mem_allocator:libc
active_defrag_running:0
lazyfree_pending_objects:0

重要指标:used_memory_rss和used_memory以及它们的比值mem_fragmentation_ratio。
当mem_fragmentation_ratio>1时,说明used_memory_rss-used_memory多出的部分内存并没有用于数据存储,而是被内存碎片所消耗,如果两者相差很大,说明碎片率严重。
当mem_fragmentation_ratio<1时,这种情况一般出现在操作系统把Redis内存交换(Swap)到硬盘导致,出现这种情况时要格外关注,由于硬盘速度远远慢于内存,Redis性能会变得很差。
内存消耗划分

内存消耗划分

对象内存:包括key和value对象的内存,尽量避免过长的key和合理使用value的类型。
缓冲内存:分为客户端缓冲、复制积压缓冲区、AOF缓冲区。

#客户端缓冲
客户端分为普通客户端、复制从客户端、订阅客户端。默认配置分别为
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
//缓冲区超过256M或者超过64M持续60s,则断开连接
client-output-buffer-limit pubsub 32mb 8mb 60
另外可以设置maxclients(默认为10000)限制连接的客户端数。

#复制积压缓冲区
用于主从复制中部分复制时,repl-backlog-size参数控制,默认1MB。可以设置较大的缓冲区空间,比如100M,避免主从全量复制。

#AOF缓冲区
用于在Redis重写期间保存最近的写入命令,AOF缓冲区空间消耗取决于AOF重写时间和写入命令量。

内存碎片:
Redis默认的内存分配器采用jemalloc,使用不太大小的内存块分配对象。
如尽量采用数字类型或者固定长度字符串等,避免内存碎片。
重启节点可以做到内存碎片重新整理,因此将碎片率过高的主节点转换为从节点,进行安全重启。

另外,执行AOF/RDB重写时Redis创建的子进程,也会内存消耗。

在开启linux的THP配置下,如果父进程有大量写命令,会加重子线程内存拷贝量。
设置sysctl vm.overcommit_memory=1允许内核可以分配所有的物理内存,防止Redis进程执行fork时因系统剩余内存不足而失败。

2、内存管理

config set maxmemory 6GB
//设置最大可用内存,由于内存碎片实际占用系统内存更大。
//超过最大可用内存,redis将执行内存溢出控制策略。

redis内存回收策略分两方面:删除过期键 和 超过最大可用内存溢出控制处理。
(1)、删除过期键
维护每个键精准的过期删除机制会导致消耗大量的CPU,所以redis才有以下两种方式:
惰性删除:
当客户端读取带有超时属性的键时,如果已经超过键设置的过期时间,会执行删除操作并返回空。但这种方式下,当过期键一直没有访问将无法得到及时删除,从而导致内存不能及时释放。
定时删除:
Redis内部维护一个定时任务,默认每秒运行10次,采用了自适应算法,根据键的过期比例、使用快慢两种速率模式回收键。

定时删除

快慢两种模式内部删除逻辑相同,只是执行的超时时间不同。慢模式每秒10次,超时判断时间为25s。快模式2s只运行一次,超时时间判断为1毫米。
(2)、内存溢出策略控制

config set maxmemory-pol-icy{policy} 动态配置。

noeviction:默认策略,不会删除任何数据,拒绝所有写入操作并返回客户端错误信息(error)OOM command not al-lowed when used memory,此时Redis只响应读操作。
volatile-lru:根据LRU(最近最少使用)算法删除设置了超时属性(expire)的键,直到腾出足够空间为止。如果没有可删除的键对象,回退到noeviction策略。
allkeys-lru:根据LRU算法删除键,不管数据有没有设置超时属性,直到腾出足够空间为止。
allkeys-random:随机删除所有键,直到腾出足够空间为止。
volatile-random:随机删除过期键,直到腾出足够空间为止。
volatile-ttl:根据键值对象的ttl属性,删除最近将要过期数据。如果没有,回退到noeviction策略。

溢出处理

频繁执行内存回收成本很高,建议线上Redis内存工作在maxmemory>used_memory状态下。

3、内存优化

缩减键值对象:key尽量简短,value可以采用potobuf序列化。
控制键的数量。

redisObject内部结构

字符串优化
字符串sds结构

字符串内部实现采用空间预分配机制,降低内存再分配次数。
字符串追加操作

字符串执行追加操作,会追加操作后字符串对象预分配了一倍容量作为预留空间,造成内存碎片率(mem_fragmentation_ratio)上升。因此,尽量减少字符串频繁修改操作如append、setrange,改为直接使用set修改字符串,降低预分配带来的内存浪费和内存碎片化。
编码优化-ziplist
编码优化

编码优化

ziplist编码是应用范围最广的一种,可以分别作为hash、list、zset类型的底层数据结构实现。•内部表现为数据紧凑排列的一块连续内存数组。

•可以模拟双向链表结构,以O(1)时间复杂度入队和出队。   
•新增删除操作涉及内存重新分配或释放,加大了操作的复杂性。   
•读写操作涉及复杂的指针移动,最坏时间复杂度为O(n2)。  
•适合存储小对象和长度有限的数据。

Redis提供了{type}-max-ziplist-value和{type}-max-ziplist-entries相关参数来做控制ziplist编码转换。
使用ziplist编码类型可以大幅降低内存占用,但影响操作的性能。因此需要考虑时间和空间的平衡,针对性能要求较高的场景使用ziplist,建议长度不要超过1000,每个元素大小控制在512字节以内。
字符串优化-intset

intset结构

整数类型划分为三种:int-16、int-32、int-64,尽量保持整数范围一致,如都在int-16范围内。防止个别大整数触发集合升级操作,产生内存浪费。

二、redis阻塞

Redis是典型的单线程架构,所有的读写操作都是在一条主线程中完成的,如果发生阻塞,将是噩梦。
阻塞可能的原因:
•内在原因包括:不合理地使用API或数据结构、CPU饱和、持久化阻塞等。
•外在原因包括:CPU竞争、内存交换、网络问题等。

不合理地使用API或数据结构:

slowlog get{n}命令可以获取最近的n条慢查询命令.
redis-cli-h{ip}-p{port}bigkeys 查询大对象

策略:修改为低算法度的命令,如hgetall改为hmget等,禁用keys、sort等命令。优化大对象使用。

CPU饱和:

根据info commandstats统计信息分析出命令不合理开销时间。

ziplist编码后hash结构内存占用会变小,但是操作变得更慢且更消耗CPU。

持久化阻塞:

fork阻塞:
fork操作发生在RDB和AOF重写时,Redis主线程调用fork操作产生共享内存的子进程,由子进程完成持久化文件重写工作。如果fork操作本身耗时过长,必然会导致主线程的阻塞。info stats命令获取到latest_fork_usec指标,表示Redis最近一次fork操作耗时,如果耗时很大,比如超过1秒,则需要做出优化调整。
AOF刷盘阻塞:
当我们开启AOF持久化功能时,文件刷盘的方式一般采用每秒一次,后台线程每秒对AOF文件做fsync操作。当硬盘压力过大时,fsync操作需要等待,直到写入完成。如果主线程发现距离上一次的fsync成功超过2秒,为了数据安全性它会阻塞直到后台线程执行fsync操作完成,这种阻塞行为主要是硬盘压力。

推荐阅读更多精彩内容