完全驱逐密钥时Redis的速度有多慢？(LRU算法)

Question

我在Java应用程序中使用Redis,我正在读取日志文件,在Redis中为每个日志存储/检索一些信息.密钥是我的日志文件中的IP地址,这意味着它们始终是新闻密钥,即使它们经常出现.

在某些时候,Redis达到了它的最大大小(在我的情况下为3gb),并开始驱逐一些键.我使用"allkeys-lru"设置,因为我想保留最年轻的密钥.

然后整个应用程序放慢了很多,比开始时长5倍.所以我有三个问题:

• 如此剧烈的放缓(5倍以上)是正常的吗？有人经历过这样的放缓吗？如果没有,我可能在我的代码中有另一个问题(因为当Redis达到极限时减速就会出现,这是不可能的)
• 我可以改进我的配置吗？我试图改变maxmemory-samples设置但没有太大的成功
• 我应该考虑替代我的特定问题吗？是否有内存数据库可以处理具有更好性能的驱逐键？我可能会考虑一个纯Java对象(HashMap ...),即使它看起来不像一个好的设计.

编辑1:我们在Redis中使用2个DB

编辑2:我们使用redis 2.2.12(ubuntu 12.04 LTS).进一步的调查解释了这个问题:我们在redis中使用db0和db1.db1的使用远小于db0,键完全不同.当Redis达到max-memory(并且LRU algo开始驱逐密钥)时,redis会删除几乎所有db1密钥,这会大大减慢所有调用.这是一种奇怪的行为,可能不常见,可能与我们的应用程序有关.我们通过转移到db1中加载的密钥的另一个(更好的)内存机制来解决问题.

谢谢 !

Answer 1

我不相信Redis是您用例的最佳选择.

Redis"LRU"只是一种尽力而为的算法(即与精确的LRU相距甚远).Redis跟踪内存分配并知道何时必须释放一些内存.在执行每个命令之前检查这一点.在"allkeys-lru"模式中驱逐密钥的机制在于选择maxmemory-samples随机密钥,比较它们的空闲时间,并选择最多空闲密钥.Redis重复这些操作,直到使用的内存低于maxmemory.

maxmemory样本越高,CPU消耗越多,但结果越准确.

如果您没有明确使用EXPIRE命令,则没有其他开销与密钥驱逐相关联.

在我的机器上使用Redis基准测试运行快速测试会产生以下吞吐量:

• 没有驱逐的情况下为145 Kops/s
• 当50%的驱逐发生时(即超过2的1个键被驱逐),125 Kops/s.

我不能重现你经历过的5倍因素.

减少驱逐开销的明显建议是减少maxmemory样本,但这也意味着精确度的显着降低.

我的建议是尝试memcached.LRU机制不同.它仍然不准确(它仅适用于每个平板),但它可能会给Redis带来更好的结果.