Redis-кеш под DST Portal полностью заполнил память

Redis-кеш под DST Portal полностью заполнил память. Как решить проблему? 

У меня возник вопрос о работе с выделенной памятью. Я установил для Redis 128 мегабайт, но он начал их заполнять. Через пару дней уже использовал 127 МБ. На сайте около 30 тысяч записей, 200 страниц, множество контента. База данных весит около 10 ГБ.

Кажется, Redis использует всю доступную память. Что делать? Добавить ещё или регулярно очищать кеш?

Нет поводов для волнений, но можно увеличить объём памяти для редиса.

Насколько будет заполнение кеша зависит от настроек (что кешировать. на сколько и тп), трафика и пр. и будет ровно столько сколько нужно для эффективной работы сайта, но не больше выделенного.

Сразу видно что база не оптимизирована. У нас записей намного больше, но база немногим превышает 500мб.

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

10 ГБ — это слабая загруженность, на самом деле. Такой объём можно полностью уместить в Redis или Tarantool.

Такая же ситуация была, с хостером решали этот вопрос вместе. Сайт с 200к+ записями. Нам в какой-то момент 32 гб стало мало при TTL кеша редис в 86400. Было решено просто добавить еще 1 плашку на 32 гб.

PS Скажу сразу что редис очень не любит когда его ограничивают в ОЗУ. При ограничении в ОЗУ начинает страдать ЦП. Замкнутый круг получается.
Итог: или откажитесь от объектного кеша или разрешите брать столько ОЗУ сколько надо или попробуйте уменьшить TTL кеша (но это тоже спорно)

В вашей ситуации заполнение Redis-кеша до предела — это ожидаемое поведение, так как Redis по умолчанию стремится использовать всю выделенную ему память. При этом важно понимать, что использование 127 МБ из 128 МБ не является проблемой само по себе, если система работает стабильно.

Однако в вашем случае с таким объемом контента (30 тысяч записей и 200 страниц) стоит рассмотреть несколько подходов к оптимизации. Во-первых, можно увеличить объем памяти для Redis, но это лишь временное решение. Более эффективным будет настроить политику выгрузки данных (eviction policy). Например, можно использовать стратегию LRU (Least Recently Used), которая будет удалять наименее используемые ключи при достижении лимита памяти.

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

Рекомендую также отслеживать метрики использования памяти и частоту промахов в кэше (miss rate), чтобы найти оптимальное соотношение между размером кэша и производительностью системы. Это поможет найти баланс между скоростью работы портала и объемом используемой памяти.

Такая же ситуация была, с хостером решали этот вопрос вместе. Сайт с 200к+ записями. Нам в какой-то момент 32 гб стало мало при TTL кеша редис в 86400. Было решено просто добавить еще 1 плашку на 32 гб.

PS Скажу сразу что редис очень не любит когда его ограничивают в ОЗУ. При ограничении в ОЗУ начинает страдать ЦП. Замкнутый круг получается.
Итог: или откажитесь от объектного кеша или разрешите брать столько ОЗУ сколько надо или попробуйте уменьшить TTL кеша (но это тоже спорно)

Игорь Симонян

Полностью согласен с вашим опытом! Действительно, Redis показывает наилучшую производительность, когда ему позволяют использовать столько памяти, сколько необходимо. Ограничение объема ОЗУ приводит к тому, что система начинает активно использовать механизм выгрузки данных, что создает дополнительную нагрузку на CPU и может существенно снизить производительность.

В вашем случае с сайтом, имеющим более 200 тысяч записей, увеличение памяти до 64 ГБ — это абсолютно правильное решение. При TTL в 86400 секунд (24 часа) такой объем данных просто физически не может уместиться в меньший объем памяти без существенного влияния на производительность.

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

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