Назад | Перейти на главную страницу

Как избежать подкачки в 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 не должны выполнять свопы

Наши соответствующие (не стандартные) настройки:

Мы связались со службой поддержки AWS и не получили особых советов: они предложили увеличить объем зарезервированной памяти (по умолчанию 0, а у нас зарезервировано 2,5 ГБ). У нас нет репликации или снимков, настроенных для этого экземпляра кэша, поэтому я считаю, что BGSAVE не должны происходить и вызывать дополнительное использование памяти.

В maxmemory cap для 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 часов.

Вот что, наконец, очень помогло: выполнение задания каждые двенадцать часов, СКАНИРОВАТЬ по всем ключам кусками (COUNT) 10000. Вот BytesUsedForCache того же экземпляра, который все еще является экземпляром cache.r3.2xlarge при еще более интенсивном использовании, чем раньше, с теми же настройками, что и раньше:

Пилообразные падения использования памяти соответствуют времени работы cron. За эти две недели использование свопа превысило ~ 45 МБ (до ~ 5 ГБ перед перезапуском). Вкладка «События кэша» в ElastiCache больше не сообщает о событиях перезапуска кэша.

Да, это похоже на кладж, который пользователи не должны делать сами, и что 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-policy) и что его нельзя изменить. Вроде бы ни что с Redis в AWS поменяем местами ..