Сколько RAM нужно для Unleash

MAATRIX

Feature flags звучат как простая идея — включил рубильник, не передеплоивая прод, — но когда доходит до self-hosted Unleash, первый вопрос обычно не "как настроить стратегию", а "сколько сервера под это закладывать". Ошибиться легко в обе стороны: взять VPS на 512 МБ и получить падающий под нагрузкой Node-процесс, либо перезаложиться на 8 ГБ под сервис, который в реальности ест 600 МБ. Разберём, из чего складывается потребление памяти у Unleash, какие цифры закладывать под разный масштаб и как выставить внятные лимиты в Docker, чтобы сервис не падал молча.

Архитектура Unleash: что реально ест память

Unleash — это не монолитный "один процесс", а связка минимум из двух компонентов, и считать память нужно по обоим:

• Unleash core (server) — написан на Node.js/TypeScript, отдаёт Admin UI (React-бандл, собранный внутрь того же процесса), Admin API и Client API, к которому обращаются SDK ваших приложений;
• PostgreSQL — единственное поддерживаемое хранилище: в нём лежат проекты, флаги, стратегии, окружения, API-токены и история изменений. Без базы core вообще не стартует;
• Unleash Edge (опционально) — отдельный лёгкий компонент на Rust, который кэширует конфигурацию флагов и снимает нагрузку по чтению с core-сервера; про него отдельно ниже.

Ключевая особенность именно Unleash среди self-hosted инструментов: сами по себе feature-флаги — крошечные JSON-объекты, и даже несколько тысяч тогглов не создают заметной нагрузки на память. Реальный драйвер потребления — не количество флагов, а количество и поведение подключённых SDK. Server-side SDK (Node.js, Java, Go, .NET, Python и т.д.) по умолчанию опрашивают /api/client/features с интервалом порядка 15 секунд и параллельно отправляют метрики использования флагов обратно на сервер. Core держит эти метрики в памяти небольшими партиями перед пакетной записью в PostgreSQL — при большом числе одновременно подключённых сервисов (не пользователей, а именно бэкенд-инстансов с SDK) буфер метрик и HTTP-соединения и есть основной источник роста RSS у Node-процесса.

Второй фактор — количество проектов и окружений: Unleash кэширует конфигурацию в памяти процесса и обновляет её по внутреннему polling-циклу, так что на сервере с 20 окружениями и активным использованием Admin UI несколькими редакторами одновременно память заметно выше, чем на одном окружении с двумя разработчиками.

Сколько RAM нужно: ориентиры по масштабу

Официальный минимум из документации Unleash рассчитан на быстрый старт и ознакомление, а не на боевую нагрузку с реальным трафиком SDK. Ниже — ориентировочные цифры для планирования; это отправная точка, а не гарантия — при сотнях подключённых сервисов и активном Admin UI у нескольких команд одновременно потребление будет выше, проверяйте по факту на своей нагрузке.

Важный нюанс: Unleash core — приложение без состояния (state целиком в PostgreSQL), поэтому масштабирование под нагрузку официально предполагается горизонтальным — несколько реплик core за балансировщиком, а не одна раздутая до огромных лимитов машина. Если вы упираетесь в память на одном инстансе при сотнях подключений, обычно правильнее поднять вторую реплику, чем удваивать RAM у первой.

Docker Compose с явными лимитами памяти

Для self-hosted установки проще всего поднять Unleash вместе с PostgreSQL через Docker Compose — так лимиты видны в одном файле, а не теряются при обновлении образа:

services:
  unleash:
    image: unleashorg/unleash-server:latest
    ports:
      - "4242:4242"
    environment:
      DATABASE_URL: postgres://unleash:${UNLEASH_DB_PASSWORD}@db/unleash
      DATABASE_SSL: "false"
      DATABASE_POOL_MIN: "2"
      DATABASE_POOL_MAX: "10"
      INIT_ADMIN_API_TOKENS: "*:*.${UNLEASH_ADMIN_TOKEN}"
      LOG_LEVEL: "warn"
      NODE_OPTIONS: "--max-old-space-size=768"
    mem_limit: 1g
    mem_reservation: 512m
    depends_on:
      - db
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "node", "-e", "require('http').get('http://localhost:4242/health', r => process.exit(r.statusCode===200?0:1))"]
      interval: 15s
      timeout: 5s
      retries: 5

  db:
    image: postgres:16
    environment:
      POSTGRES_USER: unleash
      POSTGRES_PASSWORD: ${UNLEASH_DB_PASSWORD}
      POSTGRES_DB: unleash
    volumes:
      - unleash_pg_data:/var/lib/postgresql/data
    mem_limit: 1g
    restart: unless-stopped

volumes:
  unleash_pg_data:

Пример рассчитан на профиль "стартап, один продукт" из таблицы выше: 1 ГБ на core, 1 ГБ на PostgreSQL, плюс запас под ОС и файловый кэш — итого сервер стоит брать не меньше 3 ГБ, а не ровно 2. Если PostgreSQL уже крутится у вас отдельно под другие сервисы, шаги установки чистой базы разобраны в статье про установку PostgreSQL на VPS — Unleash подключится к любому существующему инстансу через DATABASE_URL, отдельный контейнер под базу не обязателен.

Настройка Node.js и пула соединений PostgreSQL

Два параметра управляют памятью Unleash напрямую, и оба легко упустить, оставив на дефолтах.

Первый — heap самого Node.js. Без явного лимита V8 будет ориентироваться на память хоста, а не на mem_limit контейнера, и в контейнеризированном окружении это провоцирует внезапный OOM-kill вместо предсказуемого поведения. Задавайте NODE_OPTIONS=--max-old-space-size=<МБ> с запасом примерно 20-25% ниже mem_limit контейнера — так у процесса остаётся место под стек и буферы вне V8-кучи.

Второй — пул соединений к PostgreSQL, который Unleash строит поверх Knex:

DATABASE_POOL_MIN=2
DATABASE_POOL_MAX=10

Каждое активное соединение — это память и на стороне Node (буферы запросов), и на стороне PostgreSQL (по умолчанию несколько МБ на бэкенд-процесс плюс work_mem на сложные запросы). При нескольких репликах Unleash core суммарный пул от всех реплик не должен упираться в max_connections PostgreSQL — если планируете 3-4 реплики с пулом по 10, max_connections в postgresql.conf должен быть заведомо больше этого произведения с запасом под служебные подключения. Общие принципы подбора памяти для самого PostgreSQL — shared_buffers, work_mem, effective_cache_size под конкретный объём RAM — разобраны в статье про тюнинг PostgreSQL на VPS, она пригодится независимо от того, что именно ходит в базу — Unleash или другое приложение.

Unleash Edge: когда core перестаёт справляться

Если основная нагрузка — не десятки бэкенд-сервисов, а сотни или тысячи фронтенд-клиентов (frontend SDK в браузере или мобильном приложении), опрашивающих флаги напрямую, core-сервер быстро становится узким местом: каждый браузер — отдельное соединение и отдельный поток метрик. Именно для этого случая существует Unleash Edge — компонент на Rust, который разворачивается ближе к клиентам (в том же дата-центре или даже на том же сервере, что и приложение), кэширует конфигурацию флагов в памяти и отвечает на запросы SDK сам, синхронизируясь с core лишь периодически.

Практическое следствие для sizing: Edge написан на Rust без сборщика мусора JVM/V8-типа, и его память растёт линейно от объёма закэшированной конфигурации (число флагов × число окружений), а не от числа обслуживаемых клиентов — поэтому один инстанс Edge с сотнями МБ RAM спокойно обслуживает нагрузку, которая положила бы core напрямую. Типичная схема на практике: одна-две реплики core с умеренным mem_limit (1-2 ГБ каждая) плюс слой из нескольких лёгких инстансов Edge перед ними — так основная память уходит не на central server, а размазывается по дешёвым лёгким процессам ближе к нагрузке.

Добавлять Edge имеет смысл, когда вы видите рост RSS у core именно синхронно с ростом числа подключений в docker stats, а не с ростом числа флагов в проекте — это надёжный сигнал, что проблема в трафике SDK, а не в объёме конфигурации.

Как отслеживать реальное потребление памяти

Прикидки по таблице — только стартовая точка; дальше сервер нужно наблюдать по факту. Быстрый способ — штатный docker stats:

docker stats unleash db --no-stream

Более информативный вариант — встроенные Prometheus-метрики Unleash, доступные на /internal-backstage/prometheus (эндпоинт защищён отдельным токеном, если он задан). Через prom-client там экспортируются в том числе стандартные метрики процесса Node.js — process_resident_memory_bytes, использование heap, число активных хендлов — их удобно снять в Grafana и построить график роста памяти во времени вместо разовых замеров:

curl -s http://localhost:4242/internal-backstage/prometheus | grep process_resident_memory_bytes

Если видите, что память растёт ступенчато и не опускается после пиков нагрузки CI/CD (частая причина — массовые запросы к Admin API из пайплайнов при создании флагов на каждый деплой), это повод либо поднять mem_limit, либо развести нагрузку батчами. А если сервер вообще ушёл в OOM и под рукой только "добавить памяти любой ценой" — общий подход к диагностике такой ситуации на VPS разобран в статье что делать при нехватке RAM, а сами лимиты и mem_limit/mem_reservation в Docker Compose подробнее объяснены в статье про лимиты CPU и памяти в Docker.

Частые вопросы