redis field redis field 占内存吗

转载

智能开发先锋 2023-05-25 14:41:38

文章标签 java Redis sed 数据 文章分类 Redis 数据库

Redis是一个开源、高性能的Key-Value数据库，被广泛应用在服务器各种场景中。Redis 是一种内存数据库，将数据保存在内存中，读写效率要比传统的将数据保存在磁盘上的数据库要快很多。所以，监控 Redis 的内存消耗并了解 Redis 内存模型对高效并长期稳定使用 Redis 至关重要。

在介绍之前先说明下，一般生产环境下，对开发同事不会开放直连redis集群的权限，一般是提供daas平台，通过可视化命令窗口，输入redis命令，一般只有read权限；对于write操作，需要提redis数据变更单，而对于redis内存、大key、慢命令，一般都会将信息集成及中显示在监控看板，而不需要开发同事自己去输入命令；但是基本的相关知识还是要具备的。

1. 查看redis内存信息

通过 info memory 命令可以获得 Redis 内存相关的指标。

redis field redis field 占内存吗_sed

前几个字段信息最为重要，其含义分别为：

属性名	属性说明
used_memory	Redis 分配器分配的内存总量，也就是内部存储的所有数据内存占用量
used_memory_human	以可读的格式返回 used_memory
used_memory_rss	从操作系统的角度显示 Redis 进程占用的物理内存总量
used_memory_rss_human	used_memory_rss 的用户宜读格式的显示
used_memory_peak	内存使用的最大值，表示 used_memory 的峰值
used_memory_peak_human	以可读的格式返回 used_memory_peak的值

其中，当 mem_fragmentation_ratio > 1 时，说明有部分内存并没有用于数据存储，而是被内存碎片所消耗，如果该值很大，说明碎片率严重。当 mem_fragmentation_ratio < 1 时，这种情况一般出现在操作系统把 Redis 内存交换 (swap) 到硬盘导致，出现这种情况要格外关注，由于硬盘速度远远慢于内存，Redis 性能会变得很差，甚至僵死。

当 Redis 内存超出可以获得内存时，操作系统会进行 swap，将旧的页写入硬盘。从硬盘读写大概比从内存读写要慢5个数量级。used_memory 指标可以帮助判断 Redis 是否有被swap的风险或者它已经被swap。

在 Redis Administration一文建议要设置和内存一样大小的交换区，如果没有交换区，一旦 Redis 突然需要的内存大于当前操作系统可用内存时，Redis 会因为 out of memory 而被 Linix Kernel 的 OOM Killer 直接杀死。虽然当 Redis 的数据被换出 (swap out) 时，Redis的性能会变差，但是总比直接被杀死的好。

Redis 使用 maxmemory 参数限制最大可用内存。限制内存的目的主要有:

用于缓存场景，当超出内存上限 maxmemory 时使用 LRU 等删除策略释放空间。
防止所用的内存超过服务器物理内存，导致 OOM 后进程被系统杀死。

maxmemory 限制的是 Redis 实际使用的内存量，也就是 used_memory 统计项对应的内存。实际消耗的内存可能会比 maxmemory 设置的大，要小心因为这部内存导致 OOM。所以，如果你有 10GB 的内存，最好将 maxmemory 设置为 8 或者 9G

2. 内存消耗组成

Redis 进程内消耗主要包括：自身内存 + 对象内存 + 缓冲内存 + 内存碎片，其中 Redis 空进程自身内存消耗非常少；通常 used_memory_rss 在 3MB 左右时，used_memory 一般在 800KB 左右，一个空的 Redis 进程消耗内存可以忽略不计。

redis field redis field 占内存吗_Redis_02

内存消耗——1.对象内存

对象内存是 Redis 内存占用最大的一块，存储着用户所有的数据。Redis 所有的数据都采用 key-value 数据类型，每次创建键值对时，至少创建两个类型对象：key 对象和 value 对象。对象内存消耗可以简单理解为这两个对象的内存消耗之和(还有类似过期之类的信息)。键对象都是字符串，在使用 Redis 时很容易忽略键对内存消耗的影响，应当避免使用过长的键。有关 Redis 对象系统的详细内容，请看文章十二张图带你了解 Redis 的数据结构和对象系统。

内存消耗——2.缓冲内存

缓冲内存主要包括：客户端缓冲、复制积压缓冲区和 AOF 缓冲区。

（1）客户端缓冲

redis field redis field 占内存吗_java_03

客户端缓冲指的是所有接入到 Redis 服务器 TCP 连接的输入/输出缓冲。包括：普通客户端的连接（大量连接），从客户端（主要是复制的时候，异地跨机房，或者主节点下有多个从节点），订阅客户端（发布订阅功能，生产大于消费就会造成积压）；

输入缓冲无法控制，最大空间为 1G，如果超过将断开连接。而且输入缓冲区不受 maxmemory 控制，假设一个 Redis 实例设置了 maxmemory 为 4G，已经存储了 2G 数据，但是如果此时输入缓冲区使用了 3G，就已经超出了 maxmemory 限制，可能导致数据丢失、键值淘汰或者 OOM。输入缓冲区过大主要是因为 Redis 的处理速度跟不上输入缓冲区的输入速度，并且每次进入输入缓冲区的命令包含了大量的 bigkey。

普通客户端是除了复制和订阅的客户端之外的所有连接。一般普通客户端的内存消耗可以忽略不计，但是当有大量慢连接客户端接入时这部分内存消耗就不能忽略，可以设置 maxclients 做限制。特别当使用大量数据输出的命令且数据无法及时推送到客户端时，如 monitor 命令，容易造成 Redis 服务器内存突然飙升。相关案例可以查看美团在Redis上踩过的一些坑-redis内存占用飙升。

从客户端用于主从复制，主节点会为每个从节点单独建立一条连接用于命令复制。当主从节点之间网络延迟较高或主节点挂载大量从节点时这部分内存消耗将占用很大一部分，建议主节点挂载的从节点不要多于 2 个，主从节点不要部署在较差的网络环境下，如异地跨机房环境，防止复制客户端连接缓慢造成溢出。与主从复制相关的一共有两类缓冲区，一个是从客户端输出缓冲区，另外一个是下面会介绍到的复制积压缓冲区。

订阅客户端用于发布订阅功能，连接客户端使用单独的输出缓冲区，当订阅服务的消息生产快于消费速度时，输出缓冲区会产生积压造成内存空间溢出。

输入输出缓冲区在大流量场景中容易失控，造成 Redis 内存不稳定，需要重点监控！

（2）复制积压缓冲

复制积压缓冲区是Redis 在 2.8 版本后提供的一个可重用的固定大小缓冲区，用于实现部分复制功能。根据 repl-backlog-size 参数控制，默认 1MB。对于复制积压缓冲区整个主节点只有一个，所有的从节点共享此缓冲区。因此可以设置较大的缓冲区空间，比如说 100MB，可以有效避免全量复制。有关复制积压缓冲区的详情可以看文章 Redis 复制过程详解。

（3）AOF 缓冲区

AOF 重写缓冲区：这部分空间用于在 Redis AOF 重写期间保存最近的写入命令。AOF 重写缓冲区的大小用户无法控制，取决于 AOF 重写时间和写入命令量，不过一般都很小。有关 AOF 持久化的详情可以看文章 Redis AOF 持久化详解。

内存消耗——3.Redis内存碎片

Redis 默认的内存分配器采用 jemalloc，可选的分配器还有：glibc、tcmalloc。内存分配器为了更好地管理和重复利用内存，分配内存策略一般采用固定范围的内存块进行分配。具体的分配策略后续会具体讲解，但是 Redis 正常碎片率一般在 1.03 左右(为什么是这个值)。但是当存储的数据长度长度差异较大时，以下场景容易出现高内存碎片问题：

频繁做更新操作，例如频繁对已经存在的键执行 append、setrange 等更新操作。
大量过期键删除，键对象过期删除后，释放的空间无法得到重复利用，导致碎片率上升。

内存消耗——4.自身内存（子进程内存消耗）

子进程内存消耗主要指执行 AOF 重写或者进行 RDB 保存时 Redis 创建的子进程内存消耗。Redis 执行 fork 操作产生的子进程内存占用量表现为与父进程相同，理论上需要一倍的物理内存来完成相应的操作。但是 Linux 具有写时复制技术 (copy-on-write)，父子进程会共享相同的物理内存页，当父进程处理写请求时会对需要修改的页复制出一份副本完成写操作，而子进程依然读取 fork 时整个父进程的内存快照。

redis field redis field 占内存吗_Redis_04

如上图所示，fork 时只拷贝 page table，也就是页表。只有等到某一页发生修改时，才真正进行页的复制。

但是 Linux Kernel 在 2.6.38 内存增加了 Transparent Huge Pages (THP) 机制，简单理解，它就是让页大小变大，本来一页为 4KB，开启 THP 机制后，一页大小为 2MB。它虽然可以加快 fork 速度( 要拷贝的页的数量减少 )，但是会导致 copy-on-write 复制内存页的单位从 4KB 增大为 2MB，如果父进程有大量写命令，会加重内存拷贝量，都是修改一个页的内容，但是页单位变大了，从而造成过度内存消耗。例如，以下两个执行 AOF 重写时的内存消耗日志：

// 开启 THP
C * AOF rewrite: 1039 MB of memory used by copy-on-write
// 关闭 THP
C * AOF rewrite: 9MB of memory used by copy-on-write

这两个日志出自同一个 Redis 进程，used_memory 总量是 1.5GB，子进程执行期间每秒写命令量都在 200 左右。当分别开启和关闭 THP 时，子进程内存消耗有天壤之别。所以，在高并发写的场景下开启 THP，子进程内存消耗可能是父进程的数倍，造成机器物理内存溢出。

所以说，Redis 产生的子进程并不需要消耗 1 倍的父进程内存，实际消耗根据期间写入命令量决定，所以需要预留一些内存防止溢出。并且建议关闭系统的 THP，防止 copy-on-write 期间内存过度消耗。不仅是 Redis，部署 MySQL 的机器一般也会关闭 THP。

3. 内存回收策略

内存回收触发有两种情况，上面说的是一种，也就是内存使用达到maxmemory上限时候触发的溢出回收，还有一种是我们设置了过期的对象到期的时候触发的到期释放的内存回收（参考《Redis——过期时间/过期回收策略》），这里主要讲第一种。

redis配置文件中的注释文档redis.conf：http://download.redis.io/redis-stable/redis.conf

redis field redis field 占内存吗_Redis_05

Redis内存使用达到maxmemory上限时候触发的溢出回收；Redis 提供了几种策略 (maxmemory-policy) 来让用户自己决定该如何腾出新的空间以继续提供读写服务：

（1）volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
（2）volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
（3）volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
（4）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）
（5）allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
（6）no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。这个应该没人使用吧！
4.0版本后增加以下两种：
（7）volatile-lfu：从已设置过期时间的数据集(server.db[i].expires)中挑选最不经常使用的数据淘汰
（8）allkeys-lfu：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的key

redis默认的策略就是noeviction策略，如果想要配置的话，需要在配置文件中写这个配置：

maxmemory-policy volatile-lru

Redis的LRU算法

LRU是Least Recently Used 近期最少使用算法，很多缓存策略都使用了这种策略进行空间的释放，在学习操作系统的内存回收的时候也用到了这种机制进行内存的回收，类似的还有LFU（Least Frequently Used）最不经常使用算法，这种算法。

我们在上面的描述中也可以了解到，redis使用的是一种类似LRU的算法进行内存溢出回收的，其算法的代码：

/* volatile-lru and allkeys-lru policy */
else if (server.maxmemory_policy == REDIS_MAXMEMORY_ALLKEYS_LRU ||
	server.maxmemory_policy == REDIS_MAXMEMORY_VOLATILE_LRU)
{
	struct evictionPoolEntry *pool = db->eviction_pool;
 
	while(bestkey == NULL) {
		evictionPoolPopulate(dict, db->dict, db->eviction_pool);
		/* Go backward from best to worst element to evict. */
		for (k = REDIS_EVICTION_POOL_SIZE-1; k >= 0; k--) {
			if (pool[k].key == NULL) continue;
			de = dictFind(dict,pool[k].key);
 
			/* Remove the entry from the pool. */
			sdsfree(pool[k].key);
			/* Shift all elements on its right to left. */
			memmove(pool+k,pool+k+1,
				sizeof(pool[0])*(REDIS_EVICTION_POOL_SIZE-k-1));
			/* Clear the element on the right which is empty
			 * since we shifted one position to the left.  */
			pool[REDIS_EVICTION_POOL_SIZE-1].key = NULL;
			pool[REDIS_EVICTION_POOL_SIZE-1].idle = 0;
 
			/* If the key exists, is our pick. Otherwise it is
			 * a ghost and we need to try the next element. */
			if (de) {
				bestkey = dictGetKey(de);
				break;
			} else {
				/* Ghost... */
				continue;
			}
		}
	}
}

Redis会基于server.maxmemory_samples配置选取固定数目的key，然后比较它们的lru访问时间，然后淘汰最近最久没有访问的key，maxmemory_samples的值越大，Redis的近似LRU算法就越接近于严格LRU算法，但是相应消耗也变高。所以，频繁的进行这种内存回收是会降低redis性能的，主要是查找回收节点和删除需要回收节点的开销。

所以一般我们在配置redis的时候，尽量不要让它进行这种内存溢出的回收操作，redis是可以配置maxmemory，used_memory指的是redis真实占用的内存，但是由于操作系统还有其他软件以及内存碎片还有swap区的存在，所以我们实际的内存应该比redis里面设置的maxmemory要大，具体大多少视系统环境和软件环境来定。maxmemory也要比used_memory大，一般由于碎片的存在需要做1~2个G的富裕。

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。