问题缘由

---

测试反馈资料缓存100w用户，资料占据20G，和评估的差距比较大，需要分析一下原因很在。

加载前后内存对比

分析过程

---

1. 实例分析

利用ps -ef|grep redis查看启动了两个实例

两个实例

redis-cli  -h 127.0.0.1 -p 7370 -c登陆客户端，使用info memory查询信息

Redis memory信息

每个实例大概7.17G。内存碎片率mem_fragmentation_ratio大概是1.05。基本正常。

2. 版本查看

info来查看实力整体信息以及版本。

info信息

3. 记录分析

redis-cli --bigkeys -h 127.0.0.1 -p 7370 -c分析最大key信息。

最大key分析

用debug object SUBS_339828来分析最大key的就大小。

key的占用大小

利用hgetall SUBS_339828来查看记录情况

hgetall获取记录信息

查看key类型和对应的hash的field数目

key分析

小结

1、这个环境有两个实例，每个实例实际数据7.17G。峰值10G，使用率还是比较高。

2、100w数据大概有400w keys。SUBS有42个记录。每个记录大概有3K，这个占比比设想的大，实际生产应该会比这个少。

3、存在一个字段hash。改造为string方式节省空间。

4、版本较老，改为新版本，会省下一些空间。

5、配置文件hash-max-ziplist-value 缺省为64，参数可以调整为128。对于SUBS相关记录会做压缩，减少空间。对应性能影响较少，并且Fields数目越少影响越少。