Redis所有的数据都存在内存中, 当前内存虽然越来越便宜, 但跟廉价的硬盘相比成本还是比较昂贵, 因此如何高效利用Redis内存变得非常重要。 高效利用Redis内存首先需要理解Redis内存消耗在哪里, 如何管理内存, 最后才能考虑如何优化内存。 掌握这些知识后能够实现用更少的内存存储更多的数据, 从而降低成本。
本篇内容包括
1. 内存消耗分析
2. 管理内存的原理与方法
3. 内存优化技巧
理解Redis内存, 首先需要掌握Redis内存消耗在哪些方面。 有些内存消耗是必不可少的, 而有些可以通过参数调整和合理使用来规避内存浪费。 内存消耗可以分为进程自身消耗和子进程消耗。
首先需要了解Redis自身使用内存的统计数据, 可通过执行info memory命令获取内存相关指标。 读懂每个指标有助于分析Redis内存使用情况:
属性名 | 属性说明 |
---|---|
used_memory | Redis分配器分配的内存总量,内存存储的所有数据内存占用量 |
used_memory_human | 以可读的格式返回used_memory |
used_memory_rss | 以操作系统的角度显示Redis进程占用的物理内存总量 |
used_memory_peak | 内存使用的最大值 |
used_memory_peak_human | 以可读的格式返回used_memory_peak |
used_memory_lua | Lua引擎消耗的内存大小 |
mem_fragmentation_ratio | used_memory_rss/used_memory比值,表示内存碎片率 |
mem_allocator | Redis所使用的内存分配器,默认为jemalloc |
需要重点关注的指标有: used_memory_rss和used_memory以及它们的比值mem_fragmentation_ratio。
当mem_fragmentation_ratio>1时, 说明used_memory_rss - used_memory多出的部分内存并没有用于数据存储, 而是被内存碎片所消耗, 如果两者相差很大, 说明碎片率严重。
当mem_fragmentation_ratio<1时, 这种情况一般出现在操作系统把Redis内存交换(Swap)到硬盘导致, 出现这种情况时要格外关注, 由于硬盘速度远远慢于内存, Redis性能会变得很差, 甚至僵死。
Redis进程内消耗主要包括: 自身内存+对象内存+缓冲内存+内存碎片,其中Redis空进程自身内存消耗非常少, 通常used_memory_rss在3MB左右,used_memory在800KB左右, 一个空的Redis进程消耗内存可以忽略不计。Redis主要内存消耗如图所示。
客户端缓冲指的是所有接入到Redis服务器TCP连接的输入输出缓冲。输入缓冲无法控制, 最大空间为1G, 如果超过将断开连接。 输出缓冲通过参数client-output-buffer-limit控制, 如下所示:
输入输出缓冲区在大流量的场景中容易失控, 造成Redis内存的不稳定, 需要重点监控。
复制积压缓冲区:Redis在2.8版本之后提供了一个可重用的固定大小缓冲区用于实现部分复制功能, 根据repl-backlog-size参数控制, 默认1MB。对于复制积压缓冲区整个主节点只有一个, 所有的从节点共享此缓冲区, 因此可以设置较大的缓冲区空间, 如100MB, 这部分内存投入是有价值的, 可以有效避免全量复制。
AOF缓冲区: 这部分空间用于在Redis重写期间保存最近的写入命令,AOF缓冲区空间消耗用户无法控制, 消耗的内存取决于AOF重写时间和写入命令量, 这部分空间占用通常很小。
比如当保存5KB对象时jemalloc可能会采用8KB的块存储, 而剩下的3KB空间变为了内存碎片不能再分配给其他对象存储。 内存碎片问题虽然是所有内存服务的通病, 但是jemalloc针对碎片化问题专门做了优化, 一般不会存在过度碎片化的问题, 正常的碎片率(mem_fragmentation_ratio) 在1.03左右。 但是当存储的数据长短差异较大时, 以下场景容易出现高内存碎片问题:
出现高内存碎片问题时常见的解决方式如下:
子进程内存消耗主要指执行AOF/RDB重写时Redis创建的子进程内存消耗。 Redis执行fork操作产生的子进程内存占用量对外表现为与父进程相同,理论上需要一倍的物理内存来完成重写操作。 但Linux具有写时复制技术(copy-on-write) , 父子进程会共享相同的物理内存页, 当父进程处理写请求时会对需要修改的页复制出一份副本完成写操作, 而子进程依然读取fork时整个父进程的内存快照。
Linux Kernel在2.6.38内核增加了Transparent Huge Pages(THP) 机制, 而有些Linux发行版即使内核达不到2.6.38也会默认加入并开启这个功能, 如Redhat Enterprise Linux在6.0以上版本默认会引入THP。 虽然开启THP可以降低fork子进程的速度, 但之后copy-on-write期间复制内存页的单位从4KB变为2MB, 如果父进程有大量写命令, 会加重内存拷贝量, 从而造成过度内存 消耗。 例如, 以下两个执行AOF重写时的内存消耗日志:
// 开启THP:
C * AOF rewrite: 1039 MB of memory used by copy-on-write
// 关闭THP:
C * AOF rewrite: 9 MB of memory used by copy-on-write
这两个日志出自同一Redis进程, used_memory总量为1.5GB, 子进程执行期间每秒写命令量都在200左右。 当分别开启和关闭THP时, 子进程内存消耗有天壤之别。 如果在高并发写的场景下开启THP, 子进程内存消耗可能是父进程的数倍, 极易造成机器物理内存溢出, 从而触发SWAP或OOM killer。
子进程内存消耗总结如下:
Redis主要通过控制内存上限和回收策略实现内存管理, 本节将围绕这两个方面来介绍Redis如何管理内存。
Redis使用maxmemory参数限制最大可用内存。 限制内存的目的主要有:
需要注意, maxmemory限制的是Redis实际使用的内存量, 也就是used_memory统计项对应的内存。 由于内存碎片率的存在, 实际消耗的内存可能会比maxmemory设置的更大, 实际使用时要小心这部分内存溢出。 通过设置内存上限可以非常方便地实现一台服务器部署多个Redis进程的内存控制。 比如一台24GB内存的服务器, 为系统预留4GB内存, 预留4GB空闲内存给其他进程或Redis fork进程, 留给Redis16GB内存, 这样可以部署4个maxmemory=4GB的Redis进程。 得益于Redis单线程架构和内存限制机制, 即使没有采用虚拟化, 不同的Redis进程之间也可以很好地实现CPU和内存的隔离性。
Redis的内存上限可以通过config set maxmemory进行动态修改, 即修改最大可用内存。 例如之前的示例, 当发现Redis-2没有做好内存预估, 实际只用了不到2GB内存, 而Redis-1实例需要扩容到6GB内存才够用, 这时可以分别执行如下命令进行调整:
Redis-1>config set maxmemory 6GB
Redis-2>config set maxmemory 2GB
如果此时Redis-3和Redis-4实例也需要分别扩容到6GB, 这时超出系统物理内存限制就不能简单的通过调整maxmemory来达到扩容的目的, 需要采用在线迁移数据或者通过复制切换服务器来达到扩容的目的。
Redis默认无限使用服务器内存, 为防止极端情况下导致系统内存耗尽, 建议所有的Redis进程都要配置maxmemory。
在保证物理内存可用的情况下, 系统中所有Redis实例可以调整maxmemory参数来达到自由伸缩内存的目的。
Redis的内存回收机制主要体现在以下两个方面:
内存溢出控制策略可以采用config set maxmemory-policy{policy}动态配置。 Redis支持丰富的内存溢出应对策略, 可以根据实际需求灵活定制, 比如当设置volatile-lru策略时, 保证具有过期属性的键可以根据LRU剔除, 而未设置超时的键可以永久保留。 还可以采用allkeys-lru策略把Redis变为纯缓存服务器使用。 当Redis因为内存溢出删除键时, 可以通过执行info stats命令查看evicted_keys指标找出当前Redis服务器已剔除的键数量。
每次Redis执行命令时如果设置了maxmemory参数, 都会尝试执行回收内存操作。 当Redis一直工作在内存溢出(used_memory>maxmemory) 的状态下且设置非noeviction策略时, 会频繁地触发回收内存的操作, 影响Redis服务器的性能。 回收内存逻辑伪代码如下:
频繁执行回收内存成本很高, 主要包括查找可回收键和删除键的开销, 如果当前Redis有从节点, 回收内存操作对应的删除命令会同步到从节点, 导致写放大的问题。
建议线上Redis内存工作在maxmemory>used_memory状态下, 避免频繁内存回收开销。
对于需要收缩Redis内存的场景, 可以通过调小maxmemory来实现快速回收。 比如对一个实际占用6GB内存的进程设置maxmemory=4GB, 之后第一次执行命令时, 如果使用非noeviction策略, 它会一次性回收到maxmemory指定的内存量, 从而达到快速回收内存的目的。 注意, 此操作会导致数据丢失和短暂的阻塞问题, 一般在缓存场景下使用。
Redis所有的数据都在内存中, 而内存又是非常宝贵的资源。 如何优化内存的使用一直是Redis用户非常关注的问题。 本节深入到Redis细节中, 探索内存优化的技巧。
Redis存储的数据都使用redisObject来封装, 包括string、 hash、 list、set、 zset在内的所有数据类型。 理解redisObject对内存优化非常有帮助, 下面针对每个字段做详细说明:
其中java-built-in-serializer表示Java内置序列化方式, 更多数据见jvm-serializers项目: https://github.com/eishay/jvm-serializers/wiki, 其他语言也有各自对应的高效序列化工具。值对象除了存储二进制数据之外, 通常还会使用通用格式存储数据比如: json、 xml等作为字符串存储在Redis中。 这种方式优点是方便调试和跨语言, 但是同样的数据相比字节数组所需的空间更大, 在内存紧张的情况下, 可以使用通用压缩算法压缩json、 xml后再存入Redis, 从而降低内存占用, 例如使用GZIP压缩后的json可降低约60%的空间。
当频繁压缩解压json等文本数据时, 开发人员需要考虑压缩速度和计算开销成本, 这里推荐使用Google的Snappy压缩工具, 在特定的压缩率情况下效率远远高于GZIP等传统压缩工具, 且支持所有主流语言环境。
整数对象池在Redis中通过变量REDIS_SHARED_INTEGERS定义, 不能通过配置修改。 可以通过object refcount命令查看对象引用数验证是否启用整数对象池技术, 如下:
redis> set foo 100
OK
redis> object refcount foo
(integer) 2
redis> set bar 100
OK
redis> object refcount bar
(integer) 3
设置键foo等于100时, 直接使用共享池内整数对象, 因此引用数是2,再设置键bar等于100时, 引用数又变为3。
使用整数对象池究竟能降低多少内存? 让我们通过测试来对比对象池的内存优化效果
使用共享对象池后, 相同的数据内存使用降低30%以上。 可见当数据大量使用[0-9999]的整数时, 共享对象池可以节约大量内存。 需要注意的是对象池并不是只要存储[0-9999]的整数就可以工作。 当设置maxmemory并启用LRU相关淘汰策略如: volatile-lru, allkeys-lru时, Redis禁止使用共享对象池, 测试命令如下:
redis> set key:1 99
OK // 设置key:1=99
redis> object refcount key:1
(integer) 2 // 使用了对象共享,引用数为2
redis> config set maxmemory-policy volatile-lru
OK // 开启LRU淘汰策略
redis> set key:2 99
OK // 设置key:2=99
redis> object refcount key:2
(integer) 3 // 使用了对象共享,引用数变为3
redis> config set maxmemory 1GB
OK // 设置最大可用内存
redis> set key:3 99
OK // 设置key:3=99
redis> object refcount key:3
(integer) 1 // 未使用对象共享,引用数为1
redis> config set maxmemory-policy volatile-ttl
OK // 设置非LRU淘汰策略
redis> set key:4 99
OK // 设置key:4=99
redis> object refcount key:4
(integer) 4 // 又可以使用对象共享,引用数变为4
为什么开启maxmemory和LRU淘汰策略后对象池无效? LRU算法需要获取对象最后被访问时间, 以便淘汰最长未访问数据, 每个对象最后访问时间存储在redisObject对象的lru字段。 对象共享意味着多个引用共享同一个redisObject, 这时lru字段也会被共享, 导致无法获取每个对象的最后访问时间。 如果没有设置maxmemory, 直到内存被用尽Redis也不会触发内存回收, 所以共享对象池可以正常工作。
综上所述, 共享对象池与maxmemory+LRU策略冲突, 使用时需要注意。 对于ziplist编码的值对象, 即使内部数据为整数也无法使用共享对象池, 因为ziplist使用压缩且内存连续的结构, 对象共享判断成本过高, ziplist编码细节后面内容详细说明。
为什么只有整数对象池?
首先整数对象池复用的几率最大, 其次对象共享的一个关键操作就是判断相等性, Redis之所以只有整数对象池, 是因为整数比较算法时间复杂度为O(1) , 只保留一万个整数为了防止对象池浪费。 如果是字符串判断相等性, 时间复杂度变为O(n) , 特别是长字符串更消耗性能(浮点数在Redis内部使用字符串存储) 。 对于更复杂的数据结构如hash、 list等, 相等性判断需要O(n2) 。 对于单线程的Redis来说, 这样的开销显然不合理, 因此Redis只保留整数共享对象池。
1)字符串结构 Redis没有采用原生C语言的字符串类型而是自己实现了字符串结构, 内部简单动态字符串(simple dynamic string, SDS)
Redis自身实现的字符串结构有如下特点:
2)预分配机制 因为字符串(SDS) 存在预分配机制, 日常开发中要小心预分配带来的内存浪费
从测试数据可以看出, 同样的数据追加后内存消耗非常严重, 下面我们结合图来分析这一现象。 阶段1每个字符串对象空间占用如图
阶段1插入新的字符串后, free字段保留空间为0, 总占用空间=实际占用空间+1字节, 最后1字节保存‘\0’标示结尾, 这里忽略int类型len和free字段消耗的8字节。 在阶段1原有字符串上追加60字节数据空间占用如图
追加操作后字符串对象预分配了一倍容量作为预留空间, 而且大量追加操作需要内存重新分配, 造成内存碎片率(mem_fragmentation_ratio) 上升。
直接插入与阶段2相同数据的空间占用, 如图
阶段3直接插入同等数据后, 相比阶段2节省了每个字符串对象预分配的空间, 同时降低了碎片率。
字符串之所以采用预分配的方式是防止修改操作需要不断重分配内存和字节数据拷贝。 但同样也会造成内存的浪费。 字符串预分配每次并不都是翻倍扩容, 空间预分配规则如下: 1) 第一次创建len属性等于数据实际大小, free等于0, 不做预分配。 2) 修改后如果已有free空间不够且数据小于1M, 每次预分配一倍容量。 如原有len=60byte, free=0, 再追加60byte, 预分配120byte, 总占用空间: 60byte+60byte+120byte+1byte。 3) 修改后如果已有free空间不够且数据大于1MB, 每次预分配1MB数据。 如原有len=30MB, free=0, 当再追加100byte, 预分配1MB, 总占用空间: 1MB+100byte+1MB+1byte。
尽量减少字符串频繁修改操作如append、 setrange, 改为直接使用set修改字符串, 降低预分配带来的内存浪费和内存碎片化。
{
"vid": "413368768",
"title": "搜狐屌丝男士",
"videoAlbumPic":"http://photocdn.sohu.com/60160518/vrsa_ver8400079_ae433_pic26.jpg",
"pid": "6494271",
"type": "1024",
"playlist": "6494271",
"playTime": "468"
}
分别使用字符串和hash结构测试内存表现,
根据测试结构, 第一次默认配置下使用hash类型, 内存消耗不但没有降低反而比字符串存储多出2倍, 而调整hash-max-ziplist-value=66之后内存降低为535.60M。 因为json的videoAlbumPic属性长度是65, 而hash-max-ziplistvalue默认值是64, Redis采用hashtable编码方式, 反而消耗了大量内存。 调整配置后hash类型内部编码方式变为ziplist, 相比字符串更省内存且支持属性的部分操作。 下一节将具体介绍ziplist编码优化细节。
redis> set str:1 hello
OK
redis> object encoding str:1
"embstr" // embstr编码字符串
redis> lpush list:1 1 2 3
(integer) 3
redis> object encoding list:1
"ziplist" // ziplist编码列表
Redis针对每种数据类型(type) 可以采用至少两种编码方式来实现,如下所示:
了解编码和类型对应关系之后, 我们不禁疑惑Redis为什么对一种数据结构实现多种编码方式? 主要原因是Redis作者想通过不同编码实现效率和空间的平衡。 比如当我们的存储只有10个元素的列表, 当使用双向链表数据结构时, 必然需要维护大量的内部字段如每个元素需要: 前置指针, 后置指针, 数据指针等, 造成空间浪费, 如果采用连续内存结构的压缩列表(ziplist) , 将会节省大量内存, 而由于数据长度较小, 存取操作时间复杂度即使为O(n2) 性能也可满足需求。
redis> lpush list:1 a b c d
(integer) 4 // 存储4个元素
redis> object encoding list:1
"ziplist" // 采用ziplist压缩列表编码
redis> config set list-max-ziplist-entries 4
OK // 设置列表类型ziplist编码最大允许4个元素
redis> lpush list:1 e
(integer) 5 // 写入第5个元素e
redis> object encoding list:1
"linkedlist" // 编码类型转换为链表
redis> rpop list:1
"a" // 弹出元素a
redis> llen list:1
(integer) 4 // 列表此时有4个元素
redis> object encoding list:1
"linkedlist" // 编码类型依然为链表, 未做编码回退
以上命令体现了list类型编码的转换过程, 其中Redis之所以不支持编码回退, 主要是数据增删频繁时, 数据向压缩编码转换非常消耗CPU, 得不偿失。 以上示例用到了list-max-ziplist-entries参数, 这个参数用来决定列表长度在多少范围内使用ziplist编码。 当然还有其他参数控制各种数据类型的编码:
续
掌握编码转换机制, 对我们通过编码来优化内存使用非常有帮助。 下面以hash类型为例, 介绍编码转换的运行流程
理解编码转换流程和相关配置之后, 可以使用config set命令设置编码相关参数来满足使用压缩编码的条件。 对于已经采用非压缩编码类型的数据如hashtable、 linkedlist等, 设置参数后即使数据满足压缩编码条件, Redis也不会做转换, 需要重启Redis重新加载数据才能完成转换。
ziplist结构字段含义: 1) zlbytes: 记录整个压缩列表所占字节长度, 方便重新调整ziplist空间。 类型是int-32, 长度为4字节。 2) zltail: 记录距离尾节点的偏移量, 方便尾节点弹出操作。 类型是int-32, 长度为4字节。 3) zllen: 记录压缩链表节点数量, 类型是int-16, 长度为2字节。 4) entry: 记录具体的节点, 长度根据实际存储的数据而定。 a) prev_entry_bytes_length: 记录前一个节点所占空间, 用于快速定位上一个节点, 可实现列表反向迭代。 b) encoding: 标示当前节点编码和长度, 前两位表示编码类型: 字符串/整数, 其余位表示数据长度。 c) contents: 保存节点的值, 针对实际数据长度做内存占用优化。 5) zlend: 记录列表结尾, 占用一个字节。
根据以上对ziplist字段说明, 可以分析出该数据结构特点如下:
下面通过测试展示ziplist编码在不同类型中内存和速度的表现
测试数据采用100W个36字节数据, 划分为1000个键, 每个类型长度统一为1000。 从测试结果可以看出: 1) 使用ziplist可以分别作为hash、 list、 zset数据类型实现。 2) 使用ziplist编码类型可以大幅降低内存占用。 3) ziplist实现的数据类型相比原生结构, 命令操作更加耗时, 不同类型耗时排序: list<hash<zset。
ziplist压缩编码的性能表现跟值长度和元素个数密切相关, 正因为如此Redis提供了{type}-max-ziplist-value和{type}-max-ziplist-entries相关参数来做控制ziplist编码转换。 最后再次强调使用ziplist压缩编码的原则: 追求空间和时间的平衡。
针对性能要求较高的场景使用ziplist, 建议长度不要超过1000, 每个元素大小控制在512字节以内。
命令平均耗时使用info Commandstats命令获取, 包含每个命令调用次数、 总耗时、 平均耗时, 单位为微秒
redis> sadd set:test 3 4 2 6 8 9 2
(integer) 6 // 乱序写入6个整数
Redis> object encoding set:test
"intset" // 使用intset编码
Redis> smembers set:test
"2" "3" "4" "6" "8" "9" // 排序输出整数结合
redis> config set set-max-intset-entries 6
OK // 设置intset最大允许整数长度
redis> sadd set:test 5
(integer) 1 // 写入第7个整数 5
redis> object encoding set:test
"hashtable" // 编码变为hashtable
redis> smembers set:test
"8" "3" "5" "9" "4" "2" "6" // 乱序输出
以上命令可以看出intset对写入整数进行排序,通过O(log(n))时间复杂度实现查找和去重操作, intset编码结构如图
intset的字段结构含义: 1) encoding: 整数表示类型, 根据集合内最长整数值确定类型, 整数类型划分为三种: int-16、 int-32、 int-64。 2) length: 表示集合元素个数。 3) contents: 整数数组, 按从小到大顺序保存。
intset保存的整数类型根据长度划分, 当保存的整数超出当前类型时,将会触发自动升级操作且升级后不再做回退。 升级操作将会导致重新申请内存空间, 把原有数据按转换类型后拷贝到新数组。
使用intset编码的集合时, 尽量保持整数范围一致, 如都在int-16范围内。 防止个别大整数触发集合升级操作, 产生内存浪费。
下面通过测试查看ziplist编码的集合内存和速度表现
根据以上测试结果发现intset表现非常好, 同样的数据内存占用只有不到hashtable编码的十分之一。 intset数据结构插入命令复杂度为O(n) , 查询命令为O(log(n) ) , 由于整数占用空间非常小, 所以在集合长度可控的基础上, 写入命令执行速度也会非常快, 因此当使用整数集合时尽量使用intset编码。 测试第三行把ziplist-hash类型也放入其中, 主要因为intset编码必须存储整数, 当集合内保存非整数数据时, 无法使用intset实现内存优化。 这时可以使用ziplist-hash类型对象模拟集合类型, hash的field当作集合中的元素, value设置为1字节占位符即可。 使用ziplist编码的hash类型依然比使用hashtable编码的集合节省大量内存。
hash结构降低键数量分析:
通过这个测试数据, 可以说明: