Как избежать обмена на ElastiCache Redis

У нас постоянно возникают проблемы с обменом экземпляров ElastiCache Redis. Похоже, что в Amazon есть какой-то грубый внутренний мониторинг, который замечает всплески использования свопов и просто перезапускает экземпляр ElastiCache (тем самым теряя все наши кэшированные элементы). Вот диаграмма BytesUsedForCache (синяя линия) и SwapUsage (оранжевая линия) в нашем экземпляре ElastiCache за последние 14 дней:

Вы можете видеть шаблон растущего использования свопа, который, по-видимому, вызывает перезагрузку нашего экземпляра ElastiCache, при котором мы теряем все наши кэшированные элементы (BytesUsedForCache падает до 0).

На вкладке «События кэша» нашей панели инструментов ElastiCache есть соответствующие записи:

ID источника | Тип | Дата | Событие

идентификатор экземпляра кэша | кеш-кластер | Вт сен 22 07:34:47 GMT-400 2015 | Узел кэша 0001 перезапущен

идентификатор экземпляра кэша | кеш-кластер | Вт сен 22 07:34:42 GMT-400 2015 | Ошибка перезапуска механизма кэширования на узле 0001

идентификатор экземпляра кэша | кеш-кластер | Вс 20 сентября 11:13:05 GMT-400 2015 | Узел кэша 0001 перезапущен

идентификатор экземпляра кэша | кеш-кластер | Чт 17 сентября 22:59:50 GMT-400 2015 | Узел кэша 0001 перезапущен

идентификатор экземпляра кэша | кеш-кластер | Ср 16 сентября 10:36:52 GMT-400 2015 | Узел кэша 0001 перезапущен

идентификатор экземпляра кэша | кеш-кластер | Вт 15 сен 05:02:35 GMT-400 2015 | Узел кэша 0001 перезапущен

(отрежьте предыдущие записи)

Amazon утверждает :

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 ГБ). У нас нет репликации или моментальных снимков, настроенных для этого экземпляра кэша, поэтому я считаю, что BGSAVE не должны возникать и вызывать дополнительное использование памяти.

maxmemoryКрышка из cache.r3.2xlarge является 62495129600 байт, и хотя мы попали наш колпачок (минус наш reserved-memory) быстро, это мне кажется странным , что операционная система хоста будет чувствовать давление , чтобы использовать так много подкачки здесь, и так быстро, если Amazon по какой-то причине проверил настройки подкачки ОС. Любые идеи, почему мы будем вызывать так много использования свопа на ElastiCache / Redis, или обходной путь, который мы могли бы попробовать?

Поскольку здесь никто не мог ответить, подумал, что поделюсь единственной вещью, которая сработала для нас. Во-первых, эти идеи не сработали:

• больший тип экземпляра кэша: возникла та же проблема на меньших экземплярах, чем cache.r3.2xlarge, который мы используем сейчас
• настройка maxmemory-policy: ни volatile-lru, ни allkeys-lru, казалось, не имели никакого значения
• натыкаясь maxmemory-samples
• натыкаясь reserved-memory
• вынуждая всех клиентов устанавливать время истечения, обычно не более 24 часов, при этом несколько редких абонентов разрешают до 7 дней, но подавляющее большинство абонентов используют время истечения 1-6 часов.

Вот что, наконец, очень помогло: выполнение задания каждые двенадцать часов, которое запускает SCAN по всем ключам в chunks ( COUNT) из 10000. Вот BytesUsedForCache того же экземпляра, который по-прежнему является экземпляром cache.r3.2xlarge при более интенсивном использовании, чем раньше, с теми же настройками, что и раньше:

Падения пилообразной памяти в использовании памяти соответствуют временам работы cron. За этот двухнедельный период наш объем использования подкачки превысил 45 МБ (до 5 ГБ до перезапуска раньше). А на вкладке Cache Events в ElastiCache больше нет сообщений о перезапуске Cache.

Да, это похоже на ошибку, которую пользователи не должны делать сами, и что Redis должен быть достаточно умен, чтобы справиться с этой очисткой самостоятельно. Так почему же это работает? Что ж, Redis не выполняет много или какую-либо упреждающую очистку ключей с истекшим сроком, вместо этого полагаясь на исключение ключей с истекшим сроком действия во время GET . Или, если Redis обнаружит, что память заполнена, он начнет выселять ключи для каждого нового SET, но моя теория заключается в том, что Redis уже подключен.

Я знаю, что это может быть старым, но я столкнулся с этим в документации AWS.

https://aws.amazon.com/elasticache/pricing/ Они утверждают, что r3.2xlarge имеет 58,2 ГБ памяти.

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/ParameterGroups.Redis.html Они утверждают, что maxmemory системы составляет 62 ГБ (это когда политика maxmemory запустится) и что ее нельзя изменить , Кажется, что независимо от того, что с Redis в AWS мы поменяемся ..