避免在ElastiCache Redis上交换

我们的ElastiCache Redis实例交换一直遇到麻烦。亚马逊似乎已经进行了一些粗略的内部监控，这些监控注意到交换使用量激增，并只是重新启动了ElastiCache实例（从而丢失了所有缓存的项目）。这是过去14天中我们的ElastiCache实例上BytesUsedForCache（蓝线）和SwapUsage（橙线）的图表：

Redis ElastiCache BytesUsedForCache和交换

您可以看到交换使用量增加的模式似乎触发了我们的ElastiCache实例的重新启动，其中我们丢失了所有缓存的项目（BytesUsedForCache降至0）。

我们的ElastiCache仪表板的“缓存事件”选项卡具有相应的条目：

源ID | 类型日期事件

缓存实例ID | 缓存集群| 2015年9月22日星期二07:34:47 GMT-400 | 缓存节点0001重新启动

缓存实例ID | 缓存集群| 2015年9月22日星期二07:34:42 GMT-400 | 重新启动节点0001上的缓存引擎时出错

缓存实例ID | 缓存集群| 2015年9月20日，星期日11:13:05 GMT-400 | 缓存节点0001重新启动

缓存实例ID | 缓存集群| 2015年9月17日星期四22:59:50 GMT-400 | 缓存节点0001重新启动

缓存实例ID | 缓存集群| 2015年9月16日星期三10:36:52 GMT-400 | 缓存节点0001重新启动

缓存实例ID | 缓存集群| 2015年9月15日星期二05:02:35 GMT-400 | 缓存节点0001重新启动

（剪下之前的条目）

亚马逊声称：

SwapUsage-在正常使用中，Memcached和Redis均不应执行交换

我们的相关（非默认）设置：

实例类型： cache.r3.2xlarge
maxmemory-policy：allkeys-lru（以前我们一直使用默认的volatile-lru并没有太大区别）
maxmemory-samples：10
reserved-memory：2500000000
检查实例上的INFO命令，我看到mem_fragmentation_ratio介于1.00和1.05之间

我们已经联系了AWS支持人员，但没有得到很多有用的建议：他们建议提高预留的存储空间（默认值为0，并且有2.5 GB的预留空间）。我们没有为此高速缓存实例设置复制或快照，因此我认为不应发生BGSAVE并引起额外的内存使用。

maxmemorycache.r3.2xlarge 的上限为62495129600字节，尽管我们reserved-memory很快达到了上限（减去了我们的上限），但我感到奇怪的是，主机操作系统在这里如此之快地使用这么多的交换会感到压力很大，除非亚马逊出于某些原因提高了操作系统的可交换性设置。有什么想法为什么会在ElastiCache / Redis上导致大量交换使用，或者我们可以尝试解决方法？

— 乔什·库珀什密特
source

Answers:

既然没有其他人在这里得到答案，以为我会分享对我们有用的唯一方法。首先，这些想法并没有工作：

较大的缓存实例类型：在比cache小的实例上存在相同的问题。
调整maxmemory-policy：volatile-lru和allkeys-lru似乎都没有任何区别
撞上 maxmemory-samples
撞上 reserved-memory
强迫所有客户设置过期时间，通常最多24小时，少数几个罕见的呼叫者最多允许7天，但是绝大多数呼叫者使用1-6小时的过期时间。

最终，这对工作有很大帮助：每十二小时运行一次作业，对10,000个块中的所有密钥运行一次SCANCOUNT。这是同一实例的BytesUsedForCache，仍然是cache.r3.2xlarge实例，其使用量甚至比以前更大，并且设置与以前相同：

内存使用中的锯齿状下降对应于cron作业的时间。在这两个星期的时间内，我们的交换使用量达到了约45 MB（在重新启动之前达到了约5 GB）。而且，ElastiCache中的“缓存事件”选项卡不再报告任何缓存重新启动事件。

是的，这似乎是用户不必自己做的事情，Redis应该足够聪明以自行处理此清理工作。那为什么行得通呢？好吧，Redis并没有做太多或任何先发制人的清除过期密钥的操作，而是依靠在GETs期间驱逐过期密钥。或者，如果Redis意识到内存已满，那么它将开始逐出每个新SET的密钥，但是我的理论是，Redis已经被清除。

— 乔什·库珀什密特
source

乔希，想知道您在处理此问题上是否还有其他进展？我们也遇到类似的情况。您是否仍在使用与以前相同的解决方案？

— 安德鲁

@AndrewC我们仍然仍然有相同的缓存实例，来自SCAN的锯齿行为类似，并且在过去3个月中仅出现了一些挥之不去的交换使用高峰-远不及我在问题中发布的糟糕，主要是由于卸载活动远离此实例，并且SCAN答案中的工作仍在引起清理。AWS现在确实提供了Redis Cluster功能，我敢打赌这将有助于大量使用。

— Josh Kupershmidt

很高兴听到我们采用了类似的方法将缓存负载分流到单独的缓存中。您对集群如何帮助减少交换使用量的假设是什么？仅通过减少整体负荷？

— Andrew C

@JoshKupershmidt你的我的英雄。

— Moriarty

我知道这可能已经很老了，但是我在AWS文档中遇到了这个问题。

https://aws.amazon.com/elasticache/pricing/ 他们声明r3.2xlarge具有58.2gb的内存。

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/ParameterGroups.Redis.html 他们声明系统maxmemory为62gb（这是当maxmemory-policy启动时），并且无法更改。看来，无论使用AWS中的Redis，我们都将交换。

— 特林哈特
source

AWS正确-他们说maxmemory是62495129600字节，正好是58.2 GiB。链接的定价页面具有的内存单位为GiB，而不是GB。该maxmemory参数可能是不可修改的，因为Redis提供了更好的旋钮，例如reserved-memory（尽管那个并没有帮助我...），这些旋钮是可修改的，并且AWS不想让您通过例如告诉Redis来错误地配置节点。使用比Elasticache VM实际更多的内存。

— Josh Kupershmidt