Сколько памяти жрет Redis? Формула, примеры и точный калькулятор

Redis хранит данные в оперативной памяти, и каждый ключ/значение обрастает служебными структурами. Минимальный расход на одну строку (ключ+значение) можно оценить как:

Где 64 байта — служебная нагрузка на запись (тип, флаги, срок жизни), 8 байт — указатель на словарь, плюс фактические строки. Для целых чисел (int) значение может храниться в самом указателе (до 2^31). На 2026 год это правило не изменилось: Redis продолжает использовать словарь с 64-байтной записью.

Пример: ключ "user:123" (9 байт), значение "active" (6 байт). Реальный расход ≈ 64 + 8 + 9 + 6 = 87 байт. Но это без учёта выравнивания и фрагментации аллокатора памяти (jemalloc), который может дать ещё 10-30% сверху.

Для точного расчёта нужно учитывать тип данных Redis. Ниже — основные варианты:

Все цифры — на 2026 год. Важно: Redis использует jemalloc, который выделяет память блоками по степени двойки (16, 32, 48, 64, 80 и т.д.). Поэтому реальный расход может быть округлён вверх до ближайшего блока.

Рассчитаем память для типового сценария: кэш сессий. 1 млн ключей вида "session:uuid" (36-символьный UUID + префикс, всего 45 байт), значение — JSON 200 байт. Тип — String.

1. Расход на ключ: 64 (запись) + 8 (указатель) = 72 байта.
2. Плюс длина ключа: 45 байт = 117 байт.
3. Плюс длина значения: 200 байт = 317 байт на запись.
4. Учитывая jemalloc, округляем каждый "запись+данные" до ближайшего блока: 317 → 320 байт.
5. На 1 млн записей: 320 * 1 000 000 = 320 000 000 байт ≈ 305 МБ.
6. Добавляем служебный словарь: Redis хранит все ключи в глобальном словаре (ещё ~4 байта на ключ) = 4 МБ.

Итого: ~309 МБ. Плюс replication buffers, slowlog, client-буфера — может быть до 350 МБ.

Для проверки используйте Калькулятор расхода памяти Redis — он автоматически учтёт типы данных и аллокацию.

Многие разработчики удивляются, почему Redis ест в 2 раза больше ожидаемого. Типичные ловушки:

1. Срок жизни (TTL). Каждый ключ с TTL добавляет 8 байт на таймер. Если у всех ключей разный TTL — эти 8 байт превращаются в 8 МБ на 1 млн ключей.

2. Хеши со счётчиками. Если в хеше каждое поле — целое число, Redis может хранить его как int, но при превышении порога (512 полей или 64 байт на поле) переключается на hashtable, увеличивая расход в 5 раз.

3. Фрагментация. Redis использует jemalloc, который не дефрагментирует. После многих апдейтов значений разного размера память дробится. Разница занятой и используемой памяти может достигать 30%.

Следите за метриками used_memory и used_memory_rss в INFO. Если RSS > used_memory на 30% — фрагментация критична. Включите activedefrag yes (доступно с Redis 5.0, сейчас 7.x — ещё лучше).

Redis предоставляет встроенные команды для точной диагностики:

Также полезно смотреть bigkeys с помощью redis-cli --bigkeys — найдёт самые прожорливые ключи.

Онлайн-инструменты, такие как Калькулятор расхода памяти Redis, позволяют быстро прикинуть бюджет памяти без запуска Redis.

Несколько проверенных техник:

• Хеши вместо строк. Если у вас объект с 10-20 полями, храните его как хеш: HSET user:1 name "John" age 30 — при малом количестве полей (до 512) Redis использует ziplist, что даёт экономию до 70% по сравнению с JSON-строкой.
• Целые ключи. Вместо "user:1000000" используйте просто число 1000000. Redis может хранить int внутри указателя, экономя 9-30 байт на ключе.
• Выставляйте TTL, если данные не вечные. Сокращает количество мусора, но не забывайте про накладные расходы на таймер.
• Используйте list вместо set для списков без проверки дубликатов. Set (hashtable) дороже list (quicklist) на 30%.
• Обновляйте Redis до версии 7.2+. В ней улучшена работа с памятью: compact memory for small keys, новые кодировки.

После оптимизации пересчитайте потребление на калькуляторе.

Даже опытные DevOps ошибаются. Вот топ-5:

• Не учитывают служебные данные (overhead). Многие считают только размер value, забывая про 80+ байт на каждый ключ.
• Путают used_memory и used_memory_rss. Первое — реальное занятое место, второе — выделенное ОС (с учётом фрагментации). Разница может быть 2x.
• Игнорируют настройки maxmemory-policy. Если политика "allkeys-lru", Redis может вытеснять ключи, увеличивая фрагментацию.
• Считают 1 байт на символ для Unicode. В Redis строки байтовые, кириллица в UTF-8 занимает 2 байта на символ.
• Забывают про репликацию и буферы. На master+slave каждая запись дублируется. Plus client output buffer может добавить 10% к памяти.

Используйте команды из предыдущего раздела, чтобы проверить реальное потребление, а не гадать.

Для точных цифр лучше всего прогнать тесты на ваших данных. Проще всего — написать маленький скрипт на Python, который генерирует 1000 ключей и смотрит used_memory до и после:

import redis
r = redis.Redis()
before = r.info('memory')['used_memory']
for i in range(1000):
    r.set(f'key:{i}', 'x'*200)
after = r.info('memory')['used_memory']
print(f'На 1000 ключей: {(after-before)/1024:.2f} КБ')

Разделите на 1000, умножьте на 1 000 000 — получите примерное потребление для млн. Но аллокатор может вести себя нелинейно, поэтому для серьёзного проекта используйте Калькулятор расхода памяти Redis, который учитывает jemalloc и типы данных.

Также полезно прогнать официальный бенчмарк с вашими данными: redis-benchmark -P 16 -n 100000 -r 100000 -d 200 -t set. Но помните, что бенчмарк не отражает реальную фрагментацию при долгой работе.

• Используйте хеши для объектов — они дают наибольшую экономию.
• Выбирайте целочисленные ключи, если это возможно.
• Устанавливайте TTL только когда это действительно нужно, и группируйте одинаковые TTL.
• Следите за фрагментацией (used_memory_rss / used_memory). Если > 1.5, включите activedefrag.
• Перед закупкой железа — прикиньте бюджет через калькулятор.

Помните: Redis — не бездонная бочка. 1 ГБ ОЗУ на современном сервере стоит дёшево, но при 10 млрд ключей один только overhead может сожрать 800+ ГБ. Планируйте заранее.