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

一、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操作完成,这种阻塞行为主要是硬盘压力。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 157,373评论 4 361
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 66,732评论 1 290
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 107,163评论 0 238
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,700评论 0 202
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,036评论 3 286
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,425评论 1 211
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,737评论 2 310
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,421评论 0 194
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,141评论 1 239
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,398评论 2 243
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,908评论 1 257
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,276评论 2 251
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,907评论 3 233
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,018评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,772评论 0 192
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,448评论 2 269
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,325评论 2 261

推荐阅读更多精彩内容