Четыре ключевые стратегии для устранения утечек памяти и скачков потребления в Redis

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

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

Если used_memory продолжает расти, ваше приложение, вероятно, хранит больше данных, чем ожидалось. Если used_memory стабильно, но used_memory_rss скачет, обратите внимание на фрагментацию, фоновые процессы fork или операционную систему. Если оба показателя растут во время всплеска трафика и затем не снижаются, проверьте TTL, политику вытеснения и большие ключи.

Стратегия 1: Детальный мониторинг показателей использования и фрагментации

Первый шаг в диагностике любой проблемы с памятью — установить базовый уровень и понять, как Redis сообщает об использовании памяти. Стандартная команда INFO memory предоставляет ключевые метрики, которые различают память, используемую данными, и память, используемую операционной системой.

Ключевые метрики для диагностики

При возникновении скачка немедленно посмотрите на эти метрики из INFO memory:

1. used_memory: память, выделенная Redis для данных и внутренних структур.
2. used_memory_dataset: память, используемая собственно набором данных, без учета некоторых накладных расходов.
3. used_memory_rss: резидентная память, назначенная процессу Redis операционной системой.
4. mem_fragmentation_ratio: приблизительное сравнение RSS с выделенной памятью. Воспринимайте это как подсказку, а не как окончательный вердикт.

# Проверка базовой статистики памяти
redis-cli INFO memory

# Пример вывода
# used_memory:1073741824 			# 1 ГБ данных
# used_memory_rss:1509949440 		# ~1.5 ГБ в ОЗУ
# mem_fragmentation_ratio:1.40625 	# RSS примерно на 40% выше, чем used_memory

Интерпретация коэффициента фрагментации

Коэффициент около 1.0 обычно здоров. Коэффициент выше 1.5 стоит исследовать, особенно если RSS достаточно высок, чтобы угрожать хосту. Коэффициент ниже 1.0 не обязательно доказывает свопинг; это может происходить из-за пограничных случаев измерения, учета разделяемой памяти или очень маленьких наборов данных. Проверьте метрики свопинга ОС напрямую с помощью vmstat, top, sar или вашей системы мониторинга.

Если used_memory стабилен, но RSS скачет во время BGSAVE или BGREWRITEAOF, вероятной причиной является копирование при записи. Дочерний процесс записывает файл персистентности, в то время как родительский продолжает обрабатывать записи. Страницы, измененные родительским процессом, могут потребовать копирования, что временно увеличивает нагрузку на память.

Стратегия 2: Внедрение надежных политик вытеснения

Неограниченный рост — самая частая причина кажущихся "утечек" памяти в Redis. Если экземпляр используется как кэш, у него должен быть определенный потолок использования памяти, обеспечиваемый директивой maxmemory.

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

Установка maxmemory и выбор политики

Укажите максимальный лимит памяти в вашем redis.conf или с помощью CONFIG SET:

# Установить максимальный объем памяти 4 ГБ. Оставьте запас для накладных расходов Redis,
# дочерних процессов fork, кэша страниц ОС и других процессов.
CONFIG SET maxmemory 4gb

# Настройте политику вытеснения
# allkeys-lru: Вытеснять наименее недавно использованные ключи из *всего* набора данных
CONFIG SET maxmemory-policy allkeys-lru

Название политики	Описание	Случай использования
noeviction	По умолчанию. Возвращает ошибки на команды записи при достижении лимита памяти.	Базы данных, где потеря данных недопустима.
allkeys-lru	Вытесняет наименее недавно использованные ключи независимо от срока действия.	Кэширование общего назначения.
volatile-lru	Вытесняет наименее недавно использованные ключи только среди тех, у которых установлен срок действия.	Смешанные случаи использования (постоянные данные + данные кэша).
allkeys-random	Вытесняет случайные ключи при достижении лимита.	Простые хранилища сессий или там, где шаблон доступа непредсказуем.

Для чистого кэша allkeys-lru или allkeys-lfu часто является разумной отправной точкой. Для смешанного экземпляра Redis, где только некоторые ключи являются одноразовыми, volatile-lru или другая политика volatile-* может быть безопаснее, но только если каждый ключ кэша имеет срок действия. Опасная конфигурация — это кэш с noeviction, отсутствием дисциплины TTL и без предупреждения до заполнения памяти.

Стратегия 3: Диагностика и удаление скачков больших ключей

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

Использование redis-cli --bigkeys

Утилита redis-cli --bigkeys сканирует пространство ключей и сообщает о больших ключах по типу и количеству элементов. Она не измеряет точный размер в байтах и может создавать нагрузку на загруженный производственный экземпляр, поэтому запускайте ее осторожно или, по возможности, на реплике.

# Запуск анализа больших ключей
redis-cli --bigkeys

# Пример вывода (определение массивного списка)
---------- Summary ----------
...
[5] Biggest list found 'user:1001:feed' with 859387 items

Использование MEMORY USAGE (Redis 4.0+)

Чтобы определить точный размер подозрительного ключа в байтах, используйте команду MEMORY USAGE. Это важно для глубокой диагностики.

# Проверка использования памяти конкретного ключа (в байтах)
redis-cli MEMORY USAGE user:1001:feed

# Вывод: (например) 84329014

Если вы определили большие ключи, проверьте путь записи. Обычные исправления: обрезка списков с помощью LTRIM, установка срока действия для временных структур, разделение очень больших хэшей или сортированных наборов на более мелкие разделы по ключам и замена чтения "загрузить все" на постраничный доступ, такой как HSCAN, SSCAN или ZSCAN. Настоящее исправление обычно заключается в поведении приложения, а не в настройке Redis.

Стратегия 4: Управление фрагментацией памяти и копированием при записи

Высокая фрагментация или внезапные скачки RSS часто ошибочно принимают за утечки данных. Эти проблемы связаны с выделением памяти, сменой объектов и персистентностью на основе fork.

Активная дефрагментация

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

Включите и настройте ее в redis.conf:

# Включить активную дефрагментацию
activedefrag yes

# Нижний и верхний пороги — это процентные значения конфигурации.
active-defrag-threshold-lower 10
active-defrag-threshold-upper 100

Снижение накладных расходов на копирование при записи

Когда Redis выполняет fork дочернего процесса для создания RDB-снимков или перезаписи AOF, ОС использует оптимизацию CoW. Если родительский процесс выполняет интенсивные записи, пока активен дочерний процесс, каждая записанная страница должна быть дублирована, что временно увеличивает used_memory_rss. Этот скачок может легко удвоить объем памяти Redis.

Шаги по смягчению:

1. Планируйте персистентность в периоды низкого трафика.
2. Оставляйте запас памяти сверх maxmemory для накладных расходов аллокатора, клиентов, буферов репликации и дочерних процессов fork. Правильный запас зависит от размера набора данных и скорости записи; измерьте его во время реального BGSAVE или BGREWRITEAOF.
3. Избегайте перекрытия тяжелой фоновой работы, такой как снимки, перезапись AOF, резервное копирование и сканирование на уровне хоста.
4. Уменьшите количество изменений во время персистентности, если пакетное задание вызывает рост из-за копирования при записи.

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

Практический поток действий при инциденте

При скачке памяти соберите факты, прежде чем перезапускать Redis. Перезапуск может скрыть улики.

Выполните:

redis-cli INFO memory
redis-cli INFO persistence
redis-cli DBSIZE
redis-cli --bigkeys

Затем спросите, что изменилось. Удалил ли деплой TTL? Остановился ли потребитель очереди, из-за чего списки начали расти? Запустило ли новое задание отчетности HGETALL на огромных хэшах? Началась ли перезапись AOF во время пика трафика? Изменился ли лимит памяти контейнера?

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