Правильный расчет параметра maxmemory в Redis: резервы памяти для данных и работы системы

Что на самом деле ограничивает maxmemory

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

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

Часть used_memory исключается при проверке на выселение: mem_not_counted_for_evict в частности, содержит временные буферы репликации и AOF. Тем не менее, эти буферы требуют реальной памяти. Это значение уже указано в used_memory и поэтому не может быть повторно включен в этот показатель без проверки.

Из этого не следует, что все клиентские хранилища или хранилища репликации не учитываются при расчете вытеснения. Кроме того, один-единственный крупный запрос может временно значительно превысить пороговое значение. Если ты maxmemory При достижении полного предела емкости контейнера не остается надежного запаса для таких отклонений и дополнительного потребления ресурсов процесса.

Поэтому при планировании необходимо отдельно ответить на два вопроса: сколько места занимают набор данных и накладные расходы Redis в рамках управления памятью? И какой дополнительный запас требуется для всей среды выполнения? Только совокупность этих двух точек зрения покажет, является ли выбранное значение, не превышающее фактический предел памяти, обоснованным.

RSS, аллокатор и пиковые значения сохранности

После пика нагрузки может used_memory снижаются, в то время как used_memory_rss остаётся высоким: Redis, хотя и освободил память через аллокатор, но она не обязательно была сразу же возвращена операционной системе. RSS описывает резидентную память процесса с точки зрения операционной системы и поэтому представляет собой иной уровень наблюдения.

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

Также mem_fragmentation_ratio не является просто процентом фрагментации. Это соотношение включает в себя и другие составляющие процесса; для анализа причин тебе следует рассматривать его вместе с имеющимися allocator_*-показатели и историю нагрузки. На основании одного-единственного соотношения невозможно определить универсальный запас прочности.

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

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

На создание реплик требуются отдельные бюджеты

Реплика, как правило, хранит копию набора данных и для этого использует собственную оперативную память. Поэтому первичный сервер и реплика являются отдельными потребителями памяти: резерв на первичном сервере не освобождает место в контейнере реплики. Планируйте ресурсы для каждого участника с учетом его собственных ограничений и наблюдаемого потребления.

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

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

Начиная с Redis 7.0, буфер реплик и очередь репликации используют одну и ту же память. mem_clients_slaves поэтому может отображать значение «0», хотя репликация занимает память. Не следует рассматривать это поле в отрыве от контекста и без проверки суммировать объем накопителя невыполненных операций и буфера реплик как полностью отдельные области.

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

Регистрация данных в памяти на трёх уровнях

Для расчета параметров тебе понадобятся данные из Redis и из среды, в которой работает экземпляр. Эти Уровень наблюдения определяет, что означает та или иная цифра: загрузка аллокатора, RSS-память процесса и использование контейнеров — это разные показатели, которые нельзя просто сложить.

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

Кроме того, для установления временной связи тебе необходимо проверить INFO persistence на активность сохранения данных и доступные значения «копирование при записи». INFO replication отображает роль и состояние репликации. Запишите эти данные отдельно для первичного сервера и реплики, чтобы при анализе данных можно было распознать смену роли или синхронизацию.

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

Расчет надежного бюджета памяти

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

Затем вычтите резервы на дополнительные эффекты RSS и аллокатора, буферы, не учтенные при вытеснении, пиковые значения персистентности и запас безопасности. Результатом будет предварительное maxmemory-Бюджет, а не внутреннее уравнение Redis. Резервы должны соответствовать тому же пределу и реалистичным одновременно возникающим нагрузкам.

Иллюстративный расчетный пример, не основанный на измерениях: из предельного объёма контейнера в 8 GiB 0,5 GiB отводится для других потребителей, 0,5 GiB — для дополнительных эффектов RSS, 0,5 GiB — для буферов, исключённых из расчёта вытеснения, 1 GiB — на пиковые значения персистентности и 0,5 GiB — на запас безопасности. В качестве предварительного значения остается 5 GiB для maxmemory.

Эти цифры не являются рекомендацией для конкретного экземпляра. В данном примере предполагается, что заложенные резервы описывают дополнительные, непересекающиеся вклады в пределы контейнера. Именно при выполнении задачи на устойчивость общие страницы памяти и механизм «копирование при записи» (Copy-on-Write) могут затруднить сопоставление; простое сложение значений RSS родительского и дочернего процессов в данном случае было бы нецелесообразно.

Избегай Двойные подсчёты: mem_not_counted_for_evict уже содержится в used_memory. Если ты исходишь из наблюдаемого общего потребления RSS или контейнеров, не следует без проверки повторно суммировать эту долю буфера. В оставшемся бюджете вытеснения должны уместиться как набор данных, так и учтенные накладные расходы Redis; затем проверь этот подход при сопоставимой нагрузке.

Сравнение политики выселения на практике

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

В случае использования исключительно кэша можно allkeys-lru подходят, если удаленные записи можно воссоздать из другого источника. В Redis алгоритм LRU является приблизительным, а не точной глобальной сортировкой. Частые удаления могут привести к увеличению количества обращений к бэкенду; поэтому важны не только свободные байты, но и коэффициент попадания в кэш, а также пропускная способность бэкенда.

Для данных, которые нельзя удалить произвольно, noeviction Другое решение: приложение должно уметь обрабатывать неудачные операции записи, а не молчаливо предполагать, что сохранение прошло успешно. Данная политика не обеспечивает ни сохранность данных, ни защиту от нехватки памяти (OOM) на уровне операционной системы или контейнера.

В случае смешанных запасов Дисциплина TTL решающее значение: одна volatile-*-Policy может выбирать только ключи со сроком действия. Если подходящих кандидатов недостаточно, один только TTL не защищает от ошибок записи. Поэтому проверьте, действительно ли кэш и важные данные должны использовать один и тот же экземпляр и одну и ту же стратегию обработки ошибок.

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

Проверка резерва под нагрузкой

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

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

С помощью команды чтения INFO stats Среди прочего, вы отслеживаете счетчик вытеснений. Анализируйте изменение этих значений за определенный интервал времени: один лишь высокий исторический показатель не говорит о том, происходит ли в данный момент вытеснение ключей. Сопоставляйте рост числа вытеснений с количеством попаданий в кэш и нагрузкой на бэкэнд, если ваше приложение предоставляет эти показатели.

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

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

Целенаправленное сужение круга поиска неисправностей в системе хранения данных

Если RSS процесса растет, пока used_memory если это происходит, сначала проанализируйте ход событий и предыдущую нагрузку. Освободившаяся память не обязательно должна сразу же возвращаться операционной системе. Показатели аллокатора с сайта INFO memory помогают в анализе ситуации; сам по себе коэффициент фрагментации не доказывает ни утечку памяти, ни её причину.

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

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

В случае прерывания работы контейнера из-за нехватки памяти, напротив, проанализируйте события платформы и потребление памяти в сравнении с лимитом контейнера. Учтите пиковые значения персистентности и других потребителей, регистрируемых в контейнере. OOM в Redis и OOM в контейнере не являются тождественными явлениями: предельный объем памяти может быть достигнут даже без предварительного ответа OOM от Redis.

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

Оценка вариантов хостинга и архитектуры Redis

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

В качестве альтернативы можно использовать Распределение нагрузки распределить потребности в памяти и объем записей между несколькими экземплярами. Это требует соответствующего распределения данных и отдельного бюджета для каждого задействованного экземпляра. При этом реплики не следует приравнивать к распределению массива данных: они, как правило, хранят копию и для этого требуют собственной оперативной памяти.

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

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

Redis Open Source, Redis Software и Redis Cloud следует рассматривать отдельно. В случае Redis Software задокументированное ограничение на размер базы данных распространяется на все первичные и репликационные шарды; из этого не следует никакого соответствующего правила для отдельного экземпляра Redis OSS. В случае Redis Cloud и других хостинговых предложений необходимо ознакомиться с конкретными условиями использования каждого продукта, а не без проверки применять данное определение.