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

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

Redis ElastiCache BytesUsedForCache и Swap

Вы можете видеть шаблон растущего использования свопа, который, по-видимому, вызывает перезагрузку нашего экземпляра 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 уже подключен.

— Джош Купершмидт
источник

Джош, просто интересно, был ли у тебя еще прогресс в работе над этим вопросом? Мы сталкиваемся с подобной ситуацией. Вы все еще используете то же решение, что и раньше?

— Андрей C

@AndrewC у нас все еще есть тот же самый экземпляр кэша, с похожим поведением пилообразной сети от SCAN, и всего лишь несколько длительных всплесков использования свопа за последние 3 месяца - нигде не так плохо, как я писал в вопросе, в основном из-за разгрузки активность в стороне от этого экземпляра, а SCANработа в ответе еще провоцирует зачистку. AWS теперь предлагает функции Redis Cluster, которые, я уверен, помогли бы при интенсивном использовании.

— Джош Купершмидт

рад слышать; мы применили аналогичный подход к разгрузке нагрузки на кэш на отдельные кэши. Какова ваша гипотеза о том, как кластеризация поможет сократить использование свопа? Просто за счет снижения общей нагрузки?

— Андрей C

@JoshKupershmidt твой мой герой.

— Мориарти

Я знаю, что это может быть старым, но я столкнулся с этим в документации 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 мы поменяемся ..

— tlindhardt
источник

AWS имеет право - они говорят, что maxmemory - это 62495129600байты, а это точно 58,2 ГиБ. Страница с ценами, на которую вы ссылаетесь, имеет объем памяти в ГБ, а не ГБ. maxmemoryПараметр, по- видимому , не модифицируемый , потому что есть лучшие ручки , предоставляемые Redis, такие как reserved-memory(хотя это один не помогла мне ...), которые являются изменяемыми и AWS не хочет , чтобы вы неправильно настроенную узел, например , говоря Redis в использовать больше памяти, чем на самом деле имеет Elasticache VM.

— Джош Купершмидт