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

MAATRIX

Metabase — самый быстрый способ дать команде дашборды без SQL: подключил базу, накликал графики, отправил ссылку. Но как только доходит до аренды сервера, все спотыкаются на одном вопросе — сколько же реально нужно оперативной памяти. Официальная документация говорит расплывчато («от 1 ГБ»), а на практике инстанс либо падает по OutOfMemoryError через неделю работы, либо простаивает на переплаченном тарифе. Разберём по цифрам: из чего складывается потребление RAM, сколько нужно для теста, а сколько — для полсотни активных пользователей.

Из чего складывается потребление памяти в Metabase

Metabase — это Java-приложение (Clojure поверх JVM), и почти всё, что вы отдаёте серверу, уходит в heap JVM. Составляющих потребления несколько:

• Базовый рантайм JVM и приложения. Сам процесс Metabase после старта занимает 300-500 МБ ещё до первого запроса — это загруженные классы, кэш метаданных схемы, встроенный Jetty-сервер.
• Кэш метаданных. Metabase хранит в памяти структуру всех подключённых баз: названия таблиц, полей, типов, связей. Чем больше баз и таблиц вы подключили (особенно с автоматическим sync и fingerprinting полей), тем больше съедает этот кэш — на базе с несколькими сотнями таблиц счёт может идти на сотни мегабайт.
• Обработка запросов. Каждый выполняемый запрос к дашборду временно держит результат в памяти до передачи в браузер или в кэш. Тяжёлые агрегации с большими выборками (десятки тысяч строк без пагинации) кратковременно, но заметно поднимают потребление.
• Кэш результатов дашбордов. Если включено кэширование (Admin → Performance → Caching), Metabase хранит результаты запросов в памяти или в собственной базе метаданных — зависит от настройки, но in-memory кэш тоже тратит heap.
• Одновременные сессии пользователей. Каждый открытый дашборд с автообновлением держит несколько активных соединений и промежуточных структур данных, пока страница открыта в браузере.

Важно понимать: сама Metabase не хранит ваши данные — она только выполняет запросы к внешней базе (Postgres, MySQL, ClickHouse, BigQuery и так далее) и рендерит результат. Поэтому объём ваших таблиц напрямую на RAM Metabase не влияет — влияет то, сколько строк одномоментно прогоняется через приложение при построении графика.

Сколько RAM нужно для теста и небольшой команды

Для знакомства с продуктом, PoC или команды до 5-10 человек с несколькими простыми дашбордами хватает скромной конфигурации.

Официальный минимум от разработчиков — 1 ГБ RAM, и на практике контейнер действительно стартует и работает на 1 ГБ, если не подключать десятки баз и не открывать одновременно много тяжёлых запросов. Но это конфигурация «на грани»: любой скачок нагрузки (например, кто-то построил новый сложный вопрос с джойном трёх таблиц) может привести к OOM. Для рабочего инстанса даже маленькой команды разумный старт — 2 ГБ RAM, это даёт запас на встроенную H2-базу метаданных (если не вынесли её в Postgres отдельно) и на пиковые запросы.

Если вы храните метаданные Metabase в той же СУБД, что и рабочие данные (не рекомендуется, но встречается), закладывайте на 300-500 МБ больше — под конкурентную нагрузку самой базы.

Сколько RAM нужно для продакшена

Когда Metabase выходит за пределы одной команды — используется в компании десятками сотрудников, на нём висят публичные дашборды или встроенная (embedded) аналитика для клиентов, — расчёт меняется.

Ключевые множители нагрузки на продакшене:

• Число одновременно открытых дашбордов. Каждый браузер с открытым дашбордом и включённым автообновлением держит нагрузку постоянно, а не разово.
• Scheduled pulses и алерты. Если у вас настроены регулярные рассылки дашбордов на почту или в Slack (Admin → Alerts), они выполняются по расписанию и могут совпадать по времени, создавая пики потребления памяти — особенно если десятки алертов настроены на одно и то же время (например, 9:00 утра).
• Embedding и публичные ссылки. Встроенная аналитика на внешнем сайте означает непредсказуемое число одновременных запросов от анонимных пользователей — тут нужен запас памяти именно под пиковую конкурентность.
• Число подключённых источников данных. Каждая база — это отдельный пул соединений и отдельный набор метаданных в кэше. 15-20 подключённых баз ощутимо весомее, чем 2-3.

Для серьёзного продакшена стоит также вынести метаданные Metabase из встроенной H2 в отдельный PostgreSQL — это не только надёжнее (H2-файл легко повредить), но и снимает часть нагрузки с процесса Metabase. Как поднять и настроить Postgres под такую роль — в статье про установку и настройку PostgreSQL на VPS.

Metabase на отдельном сервере или рядом с базой данных

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

Аргументы за отдельный сервер:

• Metabase и целевая СУБД конкурируют за RAM и CPU, особенно в момент тяжёлых аналитических запросов (full scan таблиц, агрегации без индексов) — на одном сервере это бьёт и по продакшен-нагрузке приложения.
• JVM-процесс Metabase не всегда аккуратно возвращает память ОС — если он «раздуется» под пиковой нагрузкой, соседним процессам может не хватить памяти.
• Проще масштабировать и перезапускать независимо — рестарт Metabase после апдейта не должен трогать боевую базу.

Аргументы за совместное размещение:

• Для небольших проектов (до 10-20 пользователей) экономия на отдельном VPS ощутима, а сетевая задержка между Metabase и базой на соседних серверах иногда заметнее, чем выигрыш от изоляции.
• Если основная база — уже мощный сервер с большим запасом RAM (16+ ГБ) под свою рабочую нагрузку, добавить 2-4 ГБ под Metabase рядом дешевле, чем поднимать второй инстанс.

Практическое правило: если база обслуживает продакшен-нагрузку приложения (не только аналитику) — выносите Metabase на отдельный сервер. Если база — это выделенное аналитическое хранилище (например, ClickHouse только под BI), можно ставить рядом. Сравнение ClickHouse и PostgreSQL как источника данных для аналитики разобрано в статье ClickHouse или PostgreSQL для аналитики — выбор источника напрямую влияет на то, сколько строк Metabase придётся прогонять через себя при построении графиков.

Настройка JVM heap и лимитов памяти в Docker

Metabase запускается на JVM, и по умолчанию Java сама выбирает лимит heap исходя из доступной памяти контейнера (обычно 25% от видимой RAM, если не задано иное). Это не всегда оптимально — стоит задавать лимиты явно.

Типичный docker-compose.yml с ограничением памяти и настройкой JVM:

services:
  metabase:
    image: metabase/metabase:latest
    container_name: metabase
    restart: unless-stopped
    ports:
      - "3000:3000"
    environment:
      MB_DB_TYPE: postgres
      MB_DB_DBNAME: metabase
      MB_DB_PORT: 5432
      MB_DB_USER: metabase
      MB_DB_PASS: change_me
      MB_DB_HOST: postgres
      JAVA_OPTS: "-Xms512m -Xmx2g"
    deploy:
      resources:
        limits:
          memory: 2.5g
        reservations:
          memory: 1g
    volumes:
      - metabase-data:/metabase-data
    depends_on:
      - postgres

  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: metabase
      POSTGRES_USER: metabase
      POSTGRES_PASSWORD: change_me
    volumes:
      - pg-data:/var/lib/postgresql/data

volumes:
  metabase-data:
  pg-data:

Несколько практических правил по флагам:

• -Xmx (максимальный heap) задавайте примерно на 300-500 МБ меньше, чем лимит memory в deploy.resources.limits — JVM использует память не только под heap, но и под metaspace, стеки потоков, direct buffers. Если -Xmx равен лимиту контейнера, JVM может быть убита OOM killer раньше, чем сама решит освободить память.
• -Xms (стартовый heap) имеет смысл ставить равным половине -Xmx — так JVM не тратит время на постепенное наращивание heap при первых тяжёлых запросах.
• Без запуска в Docker (systemd-сервис на голом сервере) те же флаги передаются через переменную окружения JAVA_OPTS или напрямую в команде запуска jar-файла: java -Xms512m -Xmx2g -jar metabase.jar.

Проверить фактическое потребление памяти контейнером:

docker stats metabase --no-stream

А посмотреть, сколько реально занимает heap изнутри JVM, можно через встроенный JMX или, проще, по логам старта — Metabase пишет в лог, сколько памяти доступно процессу.

Типичные проблемы с памятью и как их диагностировать

Metabase падает через несколько часов/дней работы с OutOfMemoryError. Чаще всего — либо -Xmx не задан и JVM взяла слишком много, упёршись в лимит контейнера, либо кто-то из пользователей регулярно строит вопросы без лимита строк (SELECT * без пагинации на таблице в миллионы строк). Решение: явно задать -Xmx, включить лимиты на количество строк в результатах (Admin → Settings), проверить логи на предмет тяжёлых запросов.

Дашборды стали медленно грузиться, но память вроде не кончается. Часто это не нехватка RAM, а нехватка CPU — Metabase на 1 vCPU при 10+ одновременных пользователях начинает выстраивать запросы в очередь. Добавление второго ядра иногда даёт больший эффект, чем добавление гигабайта памяти.

Контейнер перезапускается сам по себе (restart loop), в логах Docker — OOMKilled. Значит лимит memory в compose-файле оказался ниже фактического пика потребления. Проверьте через docker inspect metabase --format='{{.State.OOMKilled}}' — если true, поднимайте лимит контейнера и синхронно -Xmx.

После обновления Metabase выросло потребление памяти. Между мажорными версиями разработчики иногда меняют дефолтные значения кэша метаданных и параллелизм sync-процессов — стоит перечитывать release notes перед апдейтом на проде и держать 10-15% запаса памяти сверху именно под такие сюрпризы.

Общий совет для диагностики: держите под рукой базовый мониторинг сервера — обычные htop для беглого взгляда либо связка Prometheus + Grafana для истории потребления во времени, чтобы видеть не разовый снимок, а тренд. Как быстро развернуть такую связку, описано в статье про установку Grafana и Prometheus на VPS — сравнение с потреблением памяти самого стека мониторинга можно посмотреть в статье сколько RAM нужно для Grafana Loki, если планируете развернуть оба инструмента на одном сервере.

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