我有一个redis主人和两个奴隶。所有3个当前都在同一个unix服务器上。这3个实例使用的内存约为3.5g，3g，redis数据库中约有275000个密钥。大约4000个是散列。一套有100000个值。一张单子里有275000把钥匙。它是一个散列和集合的列表。服务器的总内存为16 GB。目前使用的是9.5 GB。持久性当前处于关闭状态。RDB文件通过强制后台保存每天写入一次。请提供任何优化建议。最大ziplist配置当前为默认值。
最佳答案
优化散列
首先，让我们看看散列。两个重要的问题-每个散列中有多少个元素，这些散列中最大的值是多少？如果满足以下条件，哈希将使用内存高效ziplist表示：len(hash) < hash-max-ziplist-entries && length-of-largest-field(hash) < hash-max-ziplist-value
您应该根据数据在redis.conf中增加这两个设置，但不要增加超过默认值的3-4倍。
优化集合
除非您提供有关用例的其他详细信息，否则100000的集合无法优化。不过，一些一般策略-
也许使用hyperloglog-您是使用集合来计算唯一元素吗？如果您运行的命令只有sadd和scard-也许您应该切换到超级日志。
也许使用bloom过滤器-您是使用集合来检查成员的存在吗？如果您运行的命令只有sadd和sismember-也许您应该实现一个bloom过滤器并使用它而不是集合。
每个元素有多大？-集合成员应该很小。如果你在存储大对象，你可能做了一些不正确的事情。
优化列表
一张275000人的单子似乎是错的。访问列表中心的元素会很慢。您确定列表是适合您的用例的数据结构吗？
将list-compress-depth更改为1或更高。在redis.conf中阅读此设置-存在折衷。但是对于包含275000个元素的列表，您肯定希望启用压缩。
工具
使用开源redis-rdb-tools分析数据集。它会告诉你每把钥匙需要多少内存。它将帮助你决定把精力集中在哪里。
你也可以参考这个memory optimization cheat sheet。
还有什么？
您对您的用例提供了很少的细节。最好的节约来自为您的用例选择正确的数据结构。我鼓励你更新你的问题，在hash/list/set中存储更多的细节。
关于memory - Redis内存优化建议，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/51314487/