Освоение управления памятью Redis для максимальной производительности

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

Хорошее управление памятью Redis — это не только "купить больше ОЗУ". Это знание того, что хранится, как долго это должно жить, что происходит при достижении лимита памяти и какие операции могут заблокировать сервер, когда ключи велики.

Понимание использования памяти Redis

Redis использует системную память для хранения всех своих данных. Когда вы выполняете SET пары ключ-значение, Redis выделяет память как для строки ключа, так и для значения, а также некоторые накладные расходы на внутренние структуры данных. Понимание различных компонентов использования памяти — первый шаг к эффективному управлению:

Память данных: Это память, потребляемая вашими фактическими данными (ключи, значения и внутренние структуры данных, такие как словари для сопоставления ключей со значениями). Размер зависит от количества и размера ваших ключей и значений, а также от выбранных структур данных (строки, хэши, списки, множества, сортированные множества).
Накладная память: Redis добавляет накладные расходы для каждого ключа, включая указатели, метаданные, информацию о сроке действия и данные, связанные с вытеснением. Небольшие агрегатные структуры могут использовать компактные кодировки, такие как listpack или intset, в зависимости от версии Redis и типа данных, в то время как более крупные структуры используют более общие представления.
Буферная память: Redis использует выходные буферы клиентов, буферы журнала репликации и буферы AOF. Большие или медленные клиенты, а также активная настройка репликации могут потреблять значительную буферную память.
Память форка: Когда Redis выполняет фоновые операции, такие как сохранение снимков RDB или перезапись файлов AOF, он создает дочерний процесс с помощью fork. Этот дочерний процесс изначально разделяет память с родительским процессом через копирование при записи (CoW). Однако любые записи в набор данных родительским процессом после fork приведут к дублированию страниц, увеличивая общий объем памяти.

Мониторинг памяти Redis

Регулярный мониторинг памяти Redis имеет решающее значение для выявления потенциальных проблем до того, как они обострятся. Основным инструментом для этого является команда INFO memory, а также MEMORY USAGE.

Команда `INFO memory`

redis-cli INFO memory

Ключевые метрики из INFO memory:

used_memory: Общее количество байтов, выделенных Redis с помощью его аллокатора (jemalloc, glibc и т. д.). Это сумма памяти, используемой вашими данными, внутренними структурами данных и временными буферами.
used_memory_human: used_memory в удобочитаемом формате.
used_memory_rss: Размер резидентного набора (RSS), объем памяти, потребляемый процессом Redis, сообщаемый операционной системой. Сюда входят собственные выделения Redis, а также память, используемая управлением памятью операционной системы, общими библиотеками и, возможно, фрагментированная память, еще не возвращенная ОС.
mem_fragmentation_ratio: Это примерно used_memory_rss / used_memory. Значение выше 1.0 является нормальным. Гораздо более высокое значение может означать фрагментацию, поведение аллокатора или RSS, который не был возвращен ОС. Значение ниже 1.0 является предупреждающим знаком, который стоит исследовать, поскольку может указывать на выгрузку памяти на диск или эффекты синхронизации измерений.
allocator_frag_bytes: Байты фрагментации, сообщаемые аллокатором памяти.
lazyfree_pending_objects: Количество объектов, ожидающих асинхронного освобождения.

Команда `MEMORY USAGE`

Чтобы проверить использование памяти отдельных ключей:

redis-cli MEMORY USAGE mykey
redis-cli MEMORY USAGE myhashkey SAMPLES 0 # Оценка для агрегатов

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

Ключевые стратегии оптимизации памяти

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

1. Оптимизация структуры данных

Redis предлагает несколько структур данных, каждая со своим поведением памяти. Правильная структура зависит от того, как приложение читает и записывает данные.

Строки: Самые простые, но будьте внимательны к большим строкам. Использование SET или GET для очень больших строк (МБ) может повлиять на производительность из-за накладных расходов на передачу по сети и памяти.
Хэши, списки, множества, сортированные множества (агрегаты): Redis может компактно кодировать небольшие агрегатные типы данных. Точные названия кодировок и пороговые значения различаются в зависимости от версии Redis, поэтому проверяйте свой redis.conf и вывод OBJECT ENCODING вместо того, чтобы предполагать, что старая терминология ziplist применяется везде.
- Совет: Держите отдельные элементы агрегата небольшими. Для хэшей предпочитайте много маленьких полей вместо нескольких больших.
- Конфигурация: Версии Redis здесь различаются. Старые версии использовали настройки *-ziplist-*; новые версии обычно используют настройки *-listpack-* для некоторых структур. Настраивайте их осторожно и тестируйте с реальными данными, потому что компактные кодировки экономят память, но могут стоить процессорного времени для определенных шаблонов доступа.

2. Лучшие практики проектирования ключей

Хотя значения обычно потребляют больше памяти, оптимизация имен ключей также важна:

Короткие, описательные ключи: Более короткие ключи экономят память, особенно когда их миллионы. Однако не жертвуйте ясностью ради крайней краткости. Стремитесь к описательным, но лаконичным именам ключей.
- Плохо: user:1000:profile:details:email
- Хорошо: user:1000:email (если вы храните только email)
Префиксы: Используйте согласованные префиксы (например, user:, product:) для организационных целей. Это оказывает минимальное влияние на память, но помогает в управлении.

3. Минимизация накладных расходов

Каждый ключ и значение имеют некоторые внутренние накладные расходы. Уменьшение количества ключей, особенно маленьких, может быть эффективным.

Хэш вместо нескольких строк: Если у вас много связанных полей для сущности, храните их в одном HASH вместо нескольких ключей STRING. Это уменьшает количество ключей верхнего уровня и связанные с ними накладные расходы.
- Пример: Вместо user:1:name, user:1:email, user:1:age используйте ключ HASH user:1 с полями name, email, age.

4. Управление фрагментацией памяти

Фрагментация памяти возникает, когда аллокатор памяти не может найти непрерывные блоки памяти нужного размера, что приводит к неиспользуемым промежуткам. Это может привести к тому, что used_memory_rss будет значительно выше, чем used_memory.

Причины: Частые вставки и удаления ключей разного размера, особенно после длительной работы аллокатора памяти.
Обнаружение: mem_fragmentation_ratio значительно выше 1.0 (например, 1.5-2.0) указывает на высокую фрагментацию.
Решения:
- Активная дефрагментация Redis 4.0+: Redis может активно дефрагментировать память без перезапуска. Включите ее с помощью activedefrag yes в redis.conf и настройте active-defrag-max-scan-time и active-defrag-cycle-min/max. Это позволяет Redis перемещать данные, уплотняя память.
- Перезапуск Redis: Самый простой, хотя и нарушающий работу, способ дефрагментации памяти — перезапустить сервер Redis. Это освобождает всю память обратно ОС, и аллокатор начинает с чистого листа. Для постоянных экземпляров убедитесь, что снимок RDB или файл AOF сохранены перед перезапуском.

# Настройки redis.conf для активной дефрагментации
activedefrag yes
active-defrag-ignore-bytes 100mb  # Не дефрагментировать, если фрагментация меньше 100 МБ
active-defrag-threshold-lower 10  # Начать дефрагментацию, если коэффициент фрагментации > 10%
active-defrag-threshold-upper 100 # Остановить дефрагментацию, если коэффициент фрагментации > 100%
active-defrag-cycle-min 1         # Минимальная нагрузка на ЦП для дефрагментации (1-100%)
active-defrag-cycle-max 20        # Максимальная нагрузка на ЦП для дефрагментации (1-100%)

Политики вытеснения: Управление `maxmemory`

Когда Redis используется как кэш, крайне важно определить, что происходит, когда память достигает заранее установленного лимита. Директива maxmemory в redis.conf устанавливает этот лимит, а maxmemory-policy определяет стратегию вытеснения.

maxmemory 2gb # Установить максимальный объем памяти 2 гигабайта
maxmemory-policy allkeys-lru # Вытеснять наименее недавно использованные ключи среди всех ключей

Распространенные опции maxmemory-policy:

noeviction: (По умолчанию) Новые записи блокируются при достижении maxmemory. Чтение все еще работает. Это хорошо для отладки, но обычно не для производственных кэшей.
allkeys-lru: Вытесняет наименее недавно использованные (LRU) ключи из всех пространств ключей (ключи с истечением срока действия или без него).
volatile-lru: Вытесняет LRU ключи только из тех ключей, у которых установлен срок действия.
allkeys-lfu: Вытесняет наименее часто используемые (LFU) ключи из всех пространств ключей.
volatile-lfu: Вытесняет LFU ключи только из тех ключей, у которых установлен срок действия.
allkeys-random: Случайным образом вытесняет ключи из всех пространств ключей.
volatile-random: Случайным образом вытесняет ключи только из тех ключей, у которых установлен срок действия.
volatile-ttl: Вытесняет ключи с наименьшим временем жизни (TTL) только из тех ключей, у которых установлен срок действия.

Выбор правильной политики:

Для общего кэширования allkeys-lru или allkeys-lfu часто являются хорошим выбором, в зависимости от того, является ли недавность или частота лучшим индикатором полезности для ваших данных.
Если вы в основном используете Redis для управления сессиями или объектами с явными сроками действия, volatile-lru или volatile-ttl могут быть более подходящими.

Предупреждение: Если для maxmemory-policy установлено значение noeviction и достигнут maxmemory, операции записи будут завершаться ошибкой, что приведет к ошибкам приложения.

Выбор значения `maxmemory`

Не устанавливайте maxmemory равным общему объему ОЗУ сервера. Оставьте место для операционной системы, накладных расходов процесса Redis, клиентских буферов, журнала репликации, копирования при записи при сохранении, агентов мониторинга и экстренного доступа по SSH.

Для экземпляра Redis, используемого только как кэш, простой отправной точкой является установка maxmemory ниже физической ОЗУ с комфортным запасом, затем наблюдайте за реальными метриками во время пиковой нагрузки и фонового сохранения. Для экземпляра с интенсивным сохранением оставьте больше запаса, потому что снимки RDB и перезаписи AOF могут временно увеличить нагрузку на память.

Опасная конфигурация — отсутствие лимита на общем хосте. Redis может конкурировать с ОС и другими службами, пока OOM killer ядра не решит, что убить. Четкий maxmemory вместе с продуманной политикой вытеснения легче анализировать.

Большие ключи — это тоже проблема задержки

Управление памятью — это не только общее количество байтов. Один огромный ключ может навредить операциям, которые выглядят безобидными.

Примеры:

redis-cli MEMORY USAGE huge:hash
redis-cli HLEN huge:hash
redis-cli LLEN queue:events

Удаление очень большого ключа с помощью DEL может заблокировать цикл событий, пока Redis освобождает память. Предпочитайте UNLINK для больших ключей, если ваша версия Redis поддерживает это:

redis-cli UNLINK huge:hash

UNLINK отсоединяет ключ и освобождает память асинхронно. Ключ быстро исчезает из пространства ключей, в то время как дорогостоящая работа по освобождению выполняется в фоновом режиме.

Для больших коллекций проектируйте с учетом ограниченных размеров. Обрезайте потоки и списки. Разделяйте большие хэши по арендаторам, временным сегментам или типам объектов, если это соответствует шаблону доступа. Хэш с миллионом полей может сэкономить некоторые накладные расходы на ключи верхнего уровня, но его может быть неудобно переносить, устанавливать срок действия, проверять или удалять.

Сохранение и накладные расходы памяти

Механизмы сохранения Redis (RDB и AOF) также взаимодействуют с памятью:

Снимки RDB: Когда Redis сохраняет файл RDB, он создает дочерний процесс с помощью fork. Во время процесса создания снимка любые записи в набор данных Redis родительским процессом приведут к дублированию страниц памяти из-за копирования при записи (CoW). Это может временно удвоить объем памяти, особенно на загруженных экземплярах с частыми сохранениями RDB.
Перезапись AOF: Аналогично, при перезаписи файла AOF (например, BGREWRITEAOF) происходит fork, что приводит к временному дублированию памяти. Сам буфер AOF также потребляет память.

Совет: По возможности планируйте сохранения RDB и перезаписи AOF в непиковые часы или убедитесь, что на вашем сервере достаточно свободной ОЗУ для обработки накладных расходов CoW.

Ленивое освобождение

Redis 4.0 представил ленивое освобождение (неблокирующее удаление), чтобы предотвратить блокировку сервера при удалении больших ключей или очистке баз данных. Вместо синхронного освобождения памяти Redis может поместить задачу освобождения памяти в фоновый поток.

lazyfree-lazy-eviction yes: Асинхронно освобождает память во время вытеснения.
lazyfree-lazy-expire yes: Асинхронно освобождает память при истечении срока действия ключей.
lazyfree-lazy-server-del yes: Асинхронно освобождает память для серверных удалений в поддерживаемых путях.
lazyfree-lazy-user-del yes: Заставляет DEL, инициированный пользователем, вести себя больше как UNLINK в версиях Redis, которые это поддерживают.

Включайте ленивое освобождение осторожно на загруженных экземплярах, чтобы уменьшить всплески задержки из-за синхронного освобождения памяти. Затем следите за lazyfree_pending_objects; если он остается высоким, фоновая работа по освобождению не успевает.

Клиентские буферы и конвейеризация

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

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

Следите за метриками клиентских буферов в INFO clients и настройте разумные лимиты для обычных, реплик и клиентов pub/sub:

client-output-buffer-limit normal 0 0 0
client-output-buffer-limit replica 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60

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

Полезная процедура проверки памяти

Когда экземпляр Redis начинает использовать больше памяти, чем ожидалось, двигайтесь от общего к частному:

Проверьте INFO memory на used_memory, RSS, фрагментацию, статистику аллокатора и ожидающие ленивые освобождения.
Проверьте INFO keyspace, чтобы увидеть, растет ли одна база данных или семейство ключей.
Выборочно проверьте большие ключи с помощью MEMORY USAGE, SCAN и команд длины, специфичных для типа.
Убедитесь, что у ключей, похожих на кэш, есть TTL.
Проверьте недавние развертывания на наличие новых имен ключей, более длинных значений или отсутствующих сроков действия.
Проверьте время сохранения и нагрузку на память, связанную с fork.
Проверьте клиентские буферы, если память скачет во время всплесков трафика.

Например, если рост памяти следует за выпуском новой функции, ищите новые ключи без срока действия:

redis-cli --scan --pattern 'feature-x:*' | head
redis-cli TTL feature-x:example

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

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