目录
一、内存统计
可以在 lua中自定义命令。
# Memory
used_memory:33805895736
used_memory_human:31.48G
used_memory_rss:42316582912
used_memory_rss_human:39.41G
used_memory_peak:44346475840
used_memory_peak_human:41.30G
total_system_memory:338519248896
total_system_memory_human:315.27G
used_memory_lua:37888
used_memory_lua_human:37.00K
maxmemory:200000000000
maxmemory_human:186.26G
maxmemory_policy:volatile-lru
mem_fragmentation_ratio:1.25
mem_allocator:jemalloc-4.0.3
二、内存划分
内存碎片是操作系统分配给的内存和实际使用的内存的差值。
例如 存了一个string类型的key。
第一次set一个key value为5byte，第二次set 的value为10byte。当再次set 一个5byte的value时，是会分配给10byte，这是由于redis SDS数据结构的特性决定的。总之申请的可能比使用的多一点。
三、内存消耗
缓冲区内存主要是在redis-cli 执行命令所需要的内存，占用比最大的还是对象内存，其大小取决于数据规模。
四、缓冲内存
输出缓冲区配置
普通客户端缓冲区
查看客户端缓冲区
127.0.0.1:6379> client list
id=178784 addr=127.0.0.1:55911 fd=62 name= age=2422 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client
其中有几个关键 qbuf=0 qbuf-free=32768 缓冲区参数，输出缓冲区的大小obl=0 oll=0，omem是输出缓冲区的内存。
查看输出缓冲区内存不为0的session
redis-cli -p 6379 client list|grep -v "omem=0"slave客户端缓冲区
主要作用就是同步主节点的写操作，或者是主从同步。
对slave缓冲区客户端的这个参数就比较记忆犹新了。因为之前主从同步的时候老是会出现TIMEOUT。
之前百思不得其解，维护人员也说不清楚何因？
主从复制一般涉及到两个变量：
1、codis-server/redis默认配置中repl-timeout的时间为60s，当复制数据的时间超过60s时，codis-server/redis master就会认为连接超时主动断开连接，也就是Connection with master lost报错。
2、复制数据占用服务器资源的大小client-output-buffer-limit参数就决定了客户端输出缓冲区内存使用量，默认client-output-buffer-limit slave 256mb 64mb 60
127.0.0.1:6379> config get client-output-buffer-limit
1) "client-output-buffer-limit"
2) "normal 0 0 0 slave 1073741824 268435456 120 pubsub 536870912 134217728 60"
127.0.0.1:6379>
可以看到slave缓冲区的hard limit设定为1024MB，soft limit设定为256MB，softsecond设定为120s，之后同步的时候就很少有timeout的情况，因为之前的设定是默认的。
127.0.0.1:6379> config set client-output-buffer-limit "slave 536870912 134217728 120"该参数调整使得主从同步变快了，但是当数据同步完成后最好将配置修改为原配置，避免占用服务器资源过高引起其他问题。
这次redis 内存居高不下 我想和调整这个参数可能有关系。
参考:https://baijiahao.baidu.com/s?id=1604054459547563109&wfr=spider&for=pc
输入缓冲区 （发送命令）
pubsub客户端缓冲区
发布订阅并暂时并未涉及。暂时不谈。
当输入缓冲区大于1G时一般会把session干掉，一般不会有问题。
来源：oschina
链接：https://my.oschina.net/u/4350688/blog/3237985