Redis крутится в памяти, и это его суперсила. Но если оставить всё “как есть”, он может внезапно стать не ускорителем, а соседем, который занял всю кухню и ещё просит добавить swap. Поэтому ограничение памяти для Redis — это не про “оптимизацию ради оптимизации”, а про контроль: сколько кэша можно держать, что делать при переполнении и как не словить внезапный OOM на сервере.
Разберёмся, как выставить maxmemory нормально, чем отличается временная настройка от постоянной, какие политики вытеснения бывают и как быстро проверить, что Redis действительно живёт в заданных рамках.
Сначала посмотри текущую картину по памяти
Подключись к Redis и посмотри, что он думает о своей памяти прямо сейчас. Это лучше, чем выставлять цифры “на глаз”.
redis-cli
Дальше в интерактивной консоли:
INFO MEMORY
Там важны несколько полей:
used_memory— сколько Redis реально съел;used_memory_rss— сколько видит ОС (может быть больше из-за аллокации/фрагментации);maxmemory— текущий лимит (0 значит “без лимита”);maxmemory_policy— что делать при достижении лимита.
Если maxmemory сейчас 0, Redis будет расти до тех пор, пока его не остановит реальность: память закончится, OOM killer придёт без звонка.
Проверка текущего maxmemory
Посмотреть значение можно так:
CONFIG GET maxmemory
Если видишь что-то вроде 1000000000, то это байты. Redis всегда говорит байтами, даже когда ты мысленно считаешь в гигабайтах.
Как выбрать лимит, чтобы потом не было сюрпризов
На практике лимит выбирают не от “сколько хочется кэша”, а от “сколько памяти можно отдать Redis, чтобы сервер оставался живой”. Если на машине крутится только Redis — можно смелее. Если рядом Nginx, PHP-FPM, база, воркер очередей и ещё что-то — лимит должен быть аккуратнее.
Очень грубое, но рабочее правило для VPS под WordPress: выдели Redis 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
Дальше смотри по факту: если кэш постоянно выбрасывает нужные ключи — значит, мало. Если Redis занимает много, а толку нет — значит, кэшироваться нечему или TTL/политика выбраны странно.
Временная настройка maxmemory (быстро проверить гипотезу)
Если нужно выставить лимит “прямо сейчас”, без правки конфигов (например, для теста), можно задать значение через CONFIG SET. Допустим, 256 MB.
CONFIG SET maxmemory 268435456
256 MB в байтах — это 256 * 1024 * 1024 = 268435456. Если не хочется считать руками, можно на сервере быстро посчитать через shell:
echo $((256*1024*1024))
Проверь, что значение применилось:
CONFIG GET maxmemory
Важно: это изменение живёт до перезапуска Redis. Перезагрузишь сервис — и лимит вернётся к тому, что в конфиге.
Постоянная настройка: правим redis.conf и живём спокойно
Нормальный, постоянный способ — задать лимит в конфиге Redis. Путь к конфигу зависит от дистрибутива и установки, но чаще всего это один из вариантов:
/etc/redis/redis.conf/etc/redis.conf/etc/redis/redis.conf.d/*.conf(если конфиг разбит на куски)
Проверить, какой конфиг использует процесс, можно так:
ps aux | grep redis-server | grep -v grep
Открой конфиг и пропиши лимит. Redis понимает и байты, и удобные суффиксы (mb, gb).
sudo nano /etc/redis/redis.conf
Добавь или измени строки:
maxmemory 256mb
Перезапусти Redis:
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 без политики вытеснения часто бесполезен
Лимит памяти — это только половина истории. Вторая половина — что Redis делает, когда память закончилась. Это задаёт maxmemory-policy. Если политика выставлена так, что ничего не вытесняется, ты начнёшь получать ошибки записи, и приложение может “просесть” сильнее, чем от отсутствия кэша.
Посмотреть текущую политику:
CONFIG GET maxmemory-policy
Самые ходовые варианты:
noeviction— ничего не вытесняем, при переполнении Redis начнёт отказывать в записи (часто больно для кэша);allkeys-lru— вытесняем “наименее недавно используемые” ключи среди всех ключей;volatile-lru— вытесняем LRU только среди ключей с TTL;allkeys-random— вытесняем случайно (быстро, но непредсказуемо);volatile-ttl— выкидываем ключи с ближайшим истечением TTL.
Для кэша в типичной связке WordPress + Redis чаще всего выбирают allkeys-lru или volatile-lru. Если плагин/приложение ставит TTL на ключи — volatile-lru может быть аккуратнее. Если 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 растёт — значит, Redis реально начал выбрасывать ключи из-за лимита. Это не всегда плохо: кэш для того и нужен. Плохо, когда вытеснение постоянно высокое, а keyspace_misses растёт — тогда кэш не успевает приносить пользу.
Онлайн наблюдение:
redis-cli --stat
Эта штука показывает активность и помогает быстро понять: Redis реально используется или просто стоит “для галочки”.
Заключение
Ограничить память Redis — простая задача, но смысл появляется только вместе с политикой вытеснения и проверкой фактического поведения. Рабочий минимум для сервера: выставить maxmemory, выбрать адекватный maxmemory-policy, затем посмотреть INFO MEMORY и INFO STATS через день-два нагрузки. Если всё спокойно, Redis перестаёт быть “чёрным ящиком” и становится предсказуемым инструментом: кэш ускоряет сайт, а сервер не умирает от жадности одного процесса.
