【问题标题】:Redis caches - when can large evictions be triggered?Redis 缓存 - 何时可以触发大型驱逐?
【发布时间】:2018-12-03 15:38:09
【问题描述】:

我们在 Azure Standard 2.5gb 上有一个 Redis 缓存。我们观察到以下行为:

我们时不时地观察到内存使用量大幅下降。似乎有很多资源正在被驱逐。

注意事项:

  • 驱逐策略是 LRU
  • 可用缓存大小为 2.5gb
  • 没有应用程序代码会驱逐如此大量的内存(最大的对象约为 80kb,而且大多数要小得多)
  • 观察到的内存下降代表数以万计的键
  • 我们很少在缓存对象上使用明确的到期日期,当我们这样做时,它们总是

我的问题是,除了应用程序逻辑显式驱逐键之外,还有其他情况 Redis 会驱逐大量密钥吗?

【问题讨论】:

  • 从未使用过 Redis Azure,但这个文档有一个关于驱逐的提示:docs.microsoft.com/en-us/azure/redis-cache/…
  • 您的驱逐是否有可能与 Azure Redis 维护间隔同时发生?如果分片离线并被允许丢失数据,这可能是一种解释。

标签: azure redis azure-redis-cache


【解决方案1】:

内存清理可能不代表驱逐。

你说“看起来”很多资源正在被驱逐,但如果你只是依靠回收的内存来实现这种外观,你可能是在追鬼。您是否检查过此图表如何与 Azure 门户中提供的 Total Keys 指标重叠?覆盖这两个系列应该可以让您查看内存回收真的是由于驱逐还是由于像Azure这样的另一个进程可能会定期在缓存实例上调用MEMORY PURGE以清理脏页面?

【讨论】:

  • 你说得对,总键数在不断增长(正如我所料)并且没有下降。我似乎找不到任何其他与内存使用量下降相关的图表。
  • 对此进行了更多思考——我们使用 Redlock.net 进行分布式锁定,它在 Redis 缓存中创建了许多轻量级对象。如果正在清除此内存,这可能是导致内存下降的原因吗?
  • @TomGullen - 我对 Redlock.net 并不特别熟悉,但我见过的几个 redis D-locking 实现确实会产生很多密钥流失,所以它确实使很明显,分布式锁跟踪键的创建和后续删除会导致大量内存分配和释放,然后,是的,有资格被 MEMORY PURGE 回收。
  • 感谢您的帮助,似乎是一个合理的解释,因此将标记为正确答案。我想这可以通过将锁定移动到不同的 Redis 缓存来轻松测试。
【解决方案2】:

您能否将您的 redis 驱逐政策更改为 noeviction,看看是否能解决您的问题?这样做意味着您必须自己管理所有内容。 https://redis.io/topics/lru-cache 有更多详情。

【讨论】:

  • 在生产环境中这样做不太舒服,不要认为这是一种选择。
猜你喜欢
  • 2018-03-23
  • 1970-01-01
  • 2018-12-13
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-10-02
  • 2018-08-20
  • 1970-01-01
相关资源
最近更新 更多