Уникнення замін на ElastiCache Redis

У нас виникають постійні проблеми з заміною нашого примірника ElastiCache Redis. Амазонка, здається, має певний внутрішній моніторинг, який помічає скачки заміни та просто перезапускає екземпляр ElastiCache (тим самим втрачаючи всі наші кешовані елементи). Ось діаграма BytesUsedForCache (синя лінія) та SwapUsage (помаранчева лінія) на нашому екземплярі ElastiCache за останні 14 днів:

Ви можете побачити схему зростаючого використання swap, яка, здається, викликає перезавантаження нашого примірника ElastiCache, в якому ми втрачаємо всі наші кешовані елементи (BytesUsedForCache падає до 0).

На вкладці "Події кешу" на інформаційній панелі ElastiCache є відповідні записи:

Ідентифікатор джерела | Тип | Дата | Подія

cache-instance-id | кеш-кластер | Чт 22 вересня 07:34:47 GMT-400 2015 | Кеш-вузол 0001 перезапущено

cache-instance-id | кеш-кластер | Чт 22 вересня 07:34:42 GMT-400 2015 | Помилка перезапуску кеш-движка на вузлі 0001

cache-instance-id | кеш-кластер | Нд 20 вересня 11:13:05 GMT-400 2015 | Кеш-вузол 0001 перезапущено

cache-instance-id | кеш-кластер | Чт 17 вересня 22:59:50 GMT-400 2015 | Кеш-вузол 0001 перезапущено

cache-instance-id | кеш-кластер | Ср 16 вересня 10:36:52 GMT-400 2015 | Кеш-вузол 0001 перезапущено

cache-instance-id | кеш-кластер | Вт 15 вересня 05:02:35 GMT-400 2015 | Кеш-вузол 0001 перезапущено

(чиніть попередні записи)

Amazon стверджує :

SwapUsage - при звичайному використанні ні Memcached, ні Redis не повинні проводити свопи

Наші відповідні налаштування (не за замовчуванням):

• Тип примірника: cache.r3.2xlarge
• maxmemory-policy: allkeys-lru (раніше ми використовували типову летючу-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швидко натискаємо на нашу кришку (мінус нашу ), мені здається дивним, що операційна система хоста відчує тиск, щоб використати тут так багато свопів, і так швидко, якщо тільки Амазонка чомусь спрацювала з налаштуваннями простоти ОС. Будь-які ідеї, чому ми б викликали стільки використання свопів на ElastiCache / Redis, чи вирішення цього питання, що ми могли б спробувати?

Оскільки тут ніхто не мав відповіді, я думав, що поділюсь єдиним, що працювало на нас. По-перше, ці ідеї не спрацювали:

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

Ось, що, нарешті, допомогло дуже багато: запуск роботи кожні дванадцять годин, який виконує сканування за всіма клавішами ( COUNT) з 10 000. Ось BytesUsedForCache того самого екземпляра, як і раніше екземпляр cache.r3.2xgege при ще більшому використанні, ніж раніше, з тими ж налаштуваннями, що і раніше:

Краплі пиляння при використанні пам’яті відповідають часам роботи cron. Протягом цього двох тижнів використання нашого обміну перевищило ~ 45 Мб (перевищує ~ 5 Гб перед тим, як перезапустити раніше). І вкладка Кеш події в ElastiCache повідомляє більше не про події перезапуску кешу.

Так, це здається хиткою, що користувачі не повинні робити самі, і що Redis повинен бути досить розумним, щоб самостійно впоратися з цим очищенням. То чому це працює? Добре, що Redis не робить чимало чи якісь попередні очищення ключів із минулим терміном, натомість покладається на виселення ключів із минулим терміном під час GET . Або, якщо Redis зрозуміє, що пам'ять заповнена, тоді вона почне видаляти ключі для кожного нового SET, але моя теорія полягає в тому, що в цей момент Redis вже розміщений.

Я знаю, що це може бути старим, але я зіткнувся з цим у документації про ани.

https://aws.amazon.com/elasticache/pricing/ Вони заявляють, що r3.2xlarge має 58,2 Гб пам'яті.

https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/ParameterGroups.Redis.html Вони стверджують, що система maxmemory становить 62gb (це коли починається maxmemory-policy) і що вона не може бути змінена . Здається, що незалежно від того, що з Redis в AWS ми будемо обмінюватися ..