Оптимизация памяти Redis: maxmemory и политика вытеснения

Redis живёт в оперативной памяти — отсюда скорость. Без лимита он может разрастись так, что на сервере кончится RAM, а OOM killer прибьёт не только redis-server. Ограничение maxmemory — это контроль: сколько кэша держать, что делать при переполнении и как не уронить соседние сервисы.

Ниже: как посмотреть текущее потребление, выставить лимит временно и постоянно, выбрать политику вытеснения и проверить, что Redis реально укладывается в рамки.

Сначала картина по памяти

Подключитесь к Redis и посмотрите, что он сообщает о памяти:

redis-cli

В консоли:

INFO MEMORY

Полезные поля:

• used_memory — сколько Redis реально занимает (логически);
• used_memory_rss — сколько видит ОС (часто больше из-за аллокатора и фрагментации);
• maxmemory — текущий лимит (0 значит без лимита);
• maxmemory_policy — что делать при достижении лимита.

Если maxmemory равен 0, Redis растёт, пока не упрётся в доступную память сервера.

Проверка текущего maxmemory

CONFIG GET maxmemory

Значение в байтах. Например, 1000000000 — это около 1 GB. В ответах Redis почти всегда работает байтами, даже если в конфиге вы писали mb/gb.

Как выбрать размер лимита

Лимит считают не от «хочу большой кэш», а от «сколько RAM можно отдать Redis, чтобы сервер оставался живым». Если на машине только Redis — можно выделить больше. Если рядом Nginx, PHP-FPM, СУБД, воркеры очередей — оставляйте запас под них и под пики.

Грубое, но рабочее ориентировочное правило для VPS с WordPress (Redis как object cache): порядка 10-25% RAM. Примеры:

• 2 GB RAM: Redis 128-256 MB
• 4 GB RAM: Redis 256-512 MB
• 8 GB RAM: Redis 512 MB — 1 GB

Дальше смотрите по факту: если полезные ключи постоянно вытесняются — мало. Если память занята, а hit rate низкий — кэшировать нечего, странные TTL или ключи без срока жизни.

Временная настройка (для теста)

Лимит «прямо сейчас», без правки файлов — через CONFIG SET. Пример на 256 MB:

CONFIG SET maxmemory 268435456

256 MB в байтах: 256 * 1024 * 1024 = 268435456. Посчитать на сервере:

echo $((256*1024*1024))

Проверка:

CONFIG GET maxmemory

Такое изменение держится до перезапуска Redis. После restart вернётся то, что прописано в конфиге (или 0, если ничего не задано).

Постоянная настройка в redis.conf

Нормальный способ — прописать лимит в конфиге. Типичные пути:

• /etc/redis/redis.conf
• /etc/redis.conf
• /etc/redis/redis.conf.d/*.conf (если конфиг разбит на include)

Какой файл реально использует процесс:

ps aux | grep redis-server | grep -v grep

Редактирование (пример):

sudo nano /etc/redis/redis.conf

В конфиге Redis понимает и байты, и суффиксы mb, gb:

maxmemory 256mb

Перезапуск сервиса (имя unit зависит от пакета):

sudo systemctl restart redis-server || sudo systemctl restart redis

Проверка после рестарта:

redis-cli CONFIG GET maxmemory
redis-cli INFO MEMORY | egrep 'used_memory:|used_memory_rss:|maxmemory:|maxmemory_policy:'

Политика вытеснения: без неё лимит часто бесполезен

maxmemory — только потолок. Вторая половина — что делать, когда память кончилась. Это maxmemory-policy. При «жёсткой» политике без вытеснения новые записи начнут получать ошибки, и приложение может просесть сильнее, чем от пустого кэша.

CONFIG GET maxmemory-policy

Частые варианты:

• noeviction — ничего не вытесняем, при переполнении отказываем в записи;
• allkeys-lru — вытесняем least recently used среди всех ключей;
• volatile-lru — LRU только среди ключей с TTL;
• allkeys-random — случайное вытеснение (быстро, но менее предсказуемо);
• volatile-ttl — предпочитаем ключи с ближайшим истечением TTL.

Для object cache WordPress чаще берут allkeys-lru или volatile-lru. Если плагин стабильно ставит TTL — volatile-варианты логичнее. Если TTL нет или он не везде — allkeys-lru обычно спокойнее.

Временно:

CONFIG SET maxmemory-policy allkeys-lru

Постоянно в конфиге:

maxmemory-policy allkeys-lru

Как понять, что Redis упирается в лимит

Статистика вытеснений и попаданий:

INFO STATS | egrep 'evicted_keys|expired_keys|keyspace_hits|keyspace_misses'

Растущий evicted_keys значит, что ключи реально выкидываются из-за лимита. Для кэша это нормально. Плохо, когда вытеснение постоянно высокое и вместе с ним растут keyspace_misses — кэш не успевает приносить пользу.

Онлайн-обзор активности:

redis-cli --stat

Помогает быстро увидеть, используется ли Redis, или процесс просто «для галочки».

Итог

Рабочий минимум: задать maxmemory, выбрать адекватный maxmemory-policy, через день-два нагрузки сверить INFO MEMORY и INFO STATS. Тогда Redis перестаёт быть «чёрным ящиком»: кэш ускоряет сайт, а один процесс не съедает всю RAM сервера.

Источники и ссылки