Redis отвечает OOM: память сервера и политика ключей

При OOM в Redis сначала различите отказ команды из-за maxmemory и завершение самого процесса из-за нехватки памяти. Если Redis работает, проверьте действующую политику и назначение ключей. Включать вытеснение безопасно только для данных, потерю которых приложение умеет корректно обработать; не каждый ключ является восстановимым кэшем.

Кто сообщил об ошибке и что продолжает работать

Сохраните точный ответ, время, команду без секретных аргументов и состояние приложения. Одно дело — сервер Redis отклонил добавление данных, другое — клиент потерял соединение с уже завершённым процессом. Надпись OOM в пересказе сотрудника не выбирает нужную ветвь расследования.

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

Если процесс завершён, нужны события его жизненного цикла и сведения о памяти среды. Документация Docker об ограничениях отдельно описывает риск завершения процессов ядром при нехватке ресурсов. Изменение политики ключей не является автоматическим объяснением уже случившегося завершения.

Лимит данных не равен всей памяти сервера

Maxmemory задаёт границу учёта данных для соответствующей политики. Redis описывает буферы репликации и AOF, которые не входят в сумму для решения о вытеснении. Поэтому нельзя приравнивать этот параметр ни к полному расходу процесса, ни ко всей доступной памяти хоста.

Сопоставьте эффективную конфигурацию Redis, ограничения контейнера или службы и ресурсы соседних приложений. Делайте это для одного периода. Снимок свободной памяти после завершения процесса не показывает, сколько оставалось перед отказом.

Мы советуем согласовать запас на среду и дополнительные расходы до повышения лимита. Если место на хосте закончилось из-за совокупной нагрузки, снятие одной границы может ухудшить положение остальных сервисов. Нужен бюджет всего размещения.

Ключи стоит классифицировать до выбора политики

Следующая таблица — предложенная инвентаризация для условного приложения. Наличие таких групп в конкретном Redis нужно подтвердить по его использованию. Содержимое пользовательских значений не требуется публиковать или пересылать для этого разбора.

Почему allkeys и volatile не решают одну задачу

В Redis-документации allkeys-политики выбирают ключи из общего набора, а volatile-политики ограничены ключами с временем истечения. Если подходящих ключей нет, volatile-варианты ведут себя как noeviction. Выбор по знакомому имени без карты данных не даёт ожидаемого результата.

Предположим, приложение хранит вместе восстановимые копии и обязательные задания. Политика для общего набора не знает их бизнес-разницы. Сначала определите, какие данные вправе исчезать и как отделить для них правила хранения.

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

Срок хранения и вытеснение нужно обсуждать отдельно

Разрешённый срок жизни значения отвечает на вопрос, когда оно больше не нужно. Допустимость вытеснения отвечает на вопрос, можно ли потерять его раньше из-за давления памяти. Для владельца функции это разные условия, даже если в реализации они затрагивают один ключ.

Не добавляйте короткий срок только ради освобождения места, если он нарушает обещанный сценарий. Сначала выясните, кто создаёт записи, когда они становятся ненужными и кто должен их удалять. Ошибка уборки может требовать исправления приложения, а не другой политики.

Как выбрать действие, не очищая всё подряд

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

Не начинайте с общей очистки. Она может убрать данные, которые приложение использует как единственное свидетельство работы. Если нужно удалить конкретную группу, её владелец должен подтвердить назначение и способ восстановления или допустимость потери.

В сопровождение сервера передайте карту данных и состояние лимитов. Изменение конфигурации без этой информации легко превращает видимую ошибку записи в незаметную потерю состояния.

Проверяйте не только исчезновение OOM

После изменения наблюдайте, принимает ли приложение нужные операции и сохраняется ли согласованный результат. Для кэша проверьте также работу основного источника при отсутствии ключа. Для обязательных данных нужны иные критерии: их нельзя объявить доступными лишь потому, что Redis отвечает.

Приёмку проводите на небольшом безопасном наборе в своей среде. Не заполняйте рабочий Redis ради демонстрации отказа. Проверки должны охватывать ожидаемую потерю восстановимого ключа и сохранность того, что терять не разрешено.

1. Установите источник OOM и состояние процесса.
2. Сохраните эффективные лимиты и наблюдения памяти за период отказа.
3. Классифицируйте группы ключей вместе с владельцами функций.
4. Выберите действие по допустимости потери, а не по одному названию политики.
5. Согласуйте запас ресурсов и способ возврата изменения.
6. Проверьте нужную операцию, отсутствие ключа и сохранность обязательных данных.
7. Закрепите контроль роста и понятное поведение при новом отказе.

Если причиной оказался жизненный цикл данных, оформите доработку приложения с владельцем и сроком хранения каждой группы. Проверяемая цель — нужные операции работают в согласованном бюджете, а потеря или отказ не остаются скрытыми.