一、保存内存信息
使用redis-cli -a iesapp info memory > memory.txt将内存信息保存到文件
二、内存信息含义:
# Memory
used_memory:8589737336 由 Redis 分配器分配的内存总量,包含了redis进程内部的开销和数据占用的内存,以字节(byte)为单位
used_memory_human:8.00G 以更直观的单位展示分配的内存总量
used_memory_rss:13926313984 向操作系统申请的内存大小。与 top 、 ps等命令的输出一致。在理想情况下, used_memory_rss 的值应该只比 used_memory 稍微高一点儿。当 rss > used ,且两者的值相差较大时,表示存在(内部或外部的)内存碎片。当 used > rss 时,表示 Redis 的部分内存被操作系统换出到交换空间了,在这种情况下,操作可能会产生明显的延迟。
used_memory_rss_human:12.97G 以更直观的单位展示向操作系统申请的内存大小
used_memory_peak:8590052144 redis的内存消耗峰值(以字节为单位)
used_memory_peak_human:8.00G 以更直观的格式返回redis的内存消耗峰值
used_memory_peak_perc:100.00% 使用内存达到峰值内存的百分比,即(used_memory/ used_memory_peak) *100%
used_memory_overhead:8533733870 Redis为了维护数据集的内部机制所需的内存开销,包括所有客户端输出缓冲区、查询缓冲区、AOF重写缓冲区和主从复制的backlog
used_memory_startup:791952 Redis服务器启动时消耗的内存
used_memory_dataset:56003466 数据占用的内存大小,即used_memory-used_memory_overhead
used_memory_dataset_perc:0.65% 数据占用的内存大小的百分比,100%*(used_memory_dataset/(used_memory-used_memory_startup))
allocator_allocated:8589767360
allocator_active:10937163776
allocator_resident:11065339904
total_system_memory:135053119488操作系统内存
total_system_memory_human:125.78G以更直观的格式显示操作系统内存
used_memory_lua:37888 Lua脚本存储占用的内存
used_memory_lua_human:37.00K以更直观的格式显示Lua脚本存储占用的内存
used_memory_scripts:0 Lua脚本使用的字节数
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:8589934592 Redis实例的最大内存配置
maxmemory_human:8.00G以更直观的格式显示Redis实例的最大内存配置
maxmemory_policy:allkeys-lfu当达到maxmemory时的淘汰策略
allocator_frag_ratio:1.27
allocator_frag_bytes:2347396416
allocator_rss_ratio:1.01
allocator_rss_bytes:128176128
rss_overhead_ratio:1.26
rss_overhead_bytes:2860974080
mem_fragmentation_ratio:1.62碎片率,used_memory_rss/ used_memory,正常情况下稍大于1。低于1,Redis实例可能会把部分数据交换到硬盘上,内存交换会严重影响Redis的性能,所以应该增加可用物理内存。大于1.5表示碎片过多。额外碎片的产生是由于Redis释放了内存块,但内存分配器并没有返回内存给操作系统,这个内存分配器是在编译时指定的,可以是libc、jemalloc或者tcmalloc。
mem_fragmentation_bytes:5336639544
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:8531269918
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0内存分配器,Redis支持glibc’s malloc、jemalloc11、tcmalloc几种不同的内存分配器,每个分配器在内存分配和碎片上都有不同的实现。不建议普通管理员修改Redis默认内存分配器,因为这需要完全理解这几种内存分配器的差异,也要重新编译Redis。
active_defrag_running:0表示没有活动的defrag任务正在运行,1表示有活动的defrag任务正在运行(defrag:表示内存碎片整理)
lazyfree_pending_objects:0 0表示不存在延迟释放的挂起对象
三、内存碎片整理
redis4.0以上可以使用新增指令来手动回收内存碎片。
获取是否开启自动内存碎片整理config get activedefrag
开启自动内存碎片整理 config set activedefrag yes
手动清理内存碎片 memory purge
配置文件如下:
# Enabled active defragmentation
# 碎片整理总开关
# activedefrag yes
# Minimum amount of fragmentation waste to start active defrag
# 内存碎片达到多少的时候开启整理
active-defrag-ignore-bytes 100mb
# Minimum percentage of fragmentation to start active defrag
# 碎片率达到百分之多少开启整理
active-defrag-threshold-lower 10
# Maximum percentage of fragmentation at which we use maximum effort
# 碎片率小余多少百分比开启整理
active-defrag-threshold-upper 100
# Minimal effort for defrag in CPU percentage
active-defrag-cycle-min 25
# Maximal effort for defrag in CPU percentage
active-defrag-cycle-max 75
四、客户端缓冲区
通过client list查看所有连接的客户端
可以看到172.20.3.3的omem=8559066736,前面说过used_memory_overhead是Redis为了维护数据集的内部机制所需的内存开销,包括所有客户端输出缓冲区、查询缓冲区、AOF重写缓冲区和主从复制的backlog。猜测这里应该是该客户端的输出缓冲区了,这样就和redis内存占用如此大对上了。
Redis的输出缓冲区用于保存执行客户端请求命令返回的结果或返回值。每个客户端都有两个输出缓冲区,一个输出缓冲区的大小是固定的,另一个输出缓冲区的大小是可变的。
之前在程序中写redis的时候,为了提高效率,写入之后并没有获取reply,导致redis的输出缓冲区一直没有清。
最后的处理方案是,由于是循环往redis中写大量数据,不需要判断是否写入成功,所以在写入后只读取一部分reply,每隔一小时重新连接redis,重连时就会将输出缓冲区占用的内存释放掉。如果是阻塞方式连接的,会导致在getreply中等待直到有reply返回,每小时重连避免了写入个数计算不正确,导致的getreply阻塞。
参考:
https://www.cnblogs.com/undefined22/p/12580818.html