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

MAATRIX

Redash — это не одно приложение, а связка из веб-сервера, фоновых воркеров, Redis и собственной Postgres-базы под метаданные. Если считать память «на глазок» как для обычного веб-сервиса, легко получить OOM Killer в самый неподходящий момент — когда десять человек одновременно открыли общий дашборд перед утренним стендапом. Разберём, из чего на самом деле складывается потребление RAM у Redash и сколько закладывать под разные сценарии — от личного проекта до команды аналитиков с десятками источников данных.

Из чего состоит Redash и почему это важно для памяти

Официальный docker-compose.yml Redash поднимает минимум пять контейнеров:

• server — веб-приложение (Flask + Gunicorn), обслуживает UI и API;
• scheduler — Celery beat, раскладывает периодические задачи по очередям;
• worker (adhoc_worker и scheduled_worker в свежих версиях) — Celery-воркеры, которые реально выполняют запросы к вашим базам данных;
• redis — брокер очередей и кеш;
• postgres — хранит сами метаданные Redash: пользователей, дашборды, сохранённые запросы, права доступа.

Ключевой момент: воркеры Redash не просто дёргают удалённую БД и ждут ответ — они забирают результат запроса целиком в память процесса, сериализуют его в JSON и только потом отдают в кеш/фронтенд. Если у вас запрос на 500 тысяч строк с десятком колонок, воркер на секунду-две реально держит этот датасет в RAM. Это главное отличие от Metabase или Grafana, где обработка результата чаще происходит потоково или с явными лимитами.

Отсюда вывод: память под Redash считается не только «сколько сервисов крутится», но и «какого размера бывают ваши тяжёлые запросы».

Базовый расчёт по компонентам

Вот ориентировочные цифры потребления в простое (idle) и под нагрузкой — именно ориентировочные, у вас на конкретных данных и версии Redash цифры могут отличаться на 20-30%:

Уже на минимальной конфигурации с одним воркером набегает 1-1.5 ГБ только на idle-простой, без единого активного пользователя. Это важно держать в голове — Redash не запустится комфортно на сервере с 1 ГБ RAM, хотя формально контейнеры стартуют.

Сколько закладывать по числу пользователей и дашбордов

Дальше всё зависит от параллелизма — сколько людей одновременно смотрят дашборды и сколько у вас scheduled-запросов, которые крутятся в фоне независимо от того, смотрит их кто-то или нет.

Личный проект / соло-аналитик, до 5 дашбордов, редкие ручные запросы

• 1 сервер, 1 scheduler, 1 воркер, redis, postgres
• 2 ГБ RAM — рабочий минимум, но без запаса на пиковые запросы
• 4 ГБ RAM — комфортно, с запасом на пару тяжёлых отчётов одновременно

Маленькая команда, 5-15 пользователей, 10-30 дашбордов с автообновлением раз в 15-60 минут

• 2 воркера (можно разделить на adhoc и scheduled очереди)
• 4-6 ГБ RAM
• На этом объёме уже стоит следить за SQLALCHEMY_POOL_SIZE и лимитами на размер результата запроса (REDASH_ROW_LIMIT), иначе один неаккуратный SELECT * без LIMIT может съесть память воркера целиком

Команда 15-50 человек, десятки источников данных (Postgres, ClickHouse, MySQL, BigQuery и т.д.), активное расписание обновлений

• 3-4 воркера, отдельные очереди под быстрые и медленные источники
• 8-12 ГБ RAM
• Здесь уже разумно вынести postgres-метабазу Redash на managed-инстанс или отдельный сервер, чтобы она не конкурировала за память с воркерами

Крупная инсталляция, 50+ пользователей, много тяжёлых scheduled-запросов

• Отдельные ноды под server/scheduler и под worker-пул
• 16+ ГБ RAM, воркеры часто масштабируют горизонтально (несколько серверов с воркерами, слушающих общий Redis)

Обратите внимание: рост числа пользователей, которые просто смотрят уже посчитанные дашборды, влияет на память сервера некритично — там работает кеш из Redis/Postgres. А вот рост числа тяжёлых или частых запросов напрямую бьёт по памяти воркеров — это два разных драйвера нагрузки, и путать их не стоит при планировании.

Настройки, которые реально экономят память

Несколько параметров в .env Redash напрямую влияют на потребление RAM:

# Ограничить число строк в результате запроса — главный рубильник
REDASH_ROW_LIMIT=10000

# Число Gunicorn-воркеров веб-сервера (по умолчанию 2 в некоторых сборках)
REDASH_WEB_WORKERS=2

# Отдельные очереди для лёгких и тяжёлых запросов —
# позволяет не держать по 1.5 ГБ на воркер "про запас" для всех подряд
REDASH_QUERY_RUNNERS=redash.query_runner.pg,redash.query_runner.clickhouse

# Concurrency воркера Celery — сколько задач параллельно
WORKERS_COUNT=2

Разделение очередей — недооценённый приём. Если у вас есть источник данных, по которому регулярно прилетают запросы на миллионы строк (например, сырые логи в ClickHouse), имеет смысл вынести его в отдельную очередь с 1 воркером и явным лимитом памяти на контейнер, а остальные источники обслуживать лёгкими воркерами с высоким concurrency.

Пример docker-compose.yml с лимитами по памяти на сервис:

services:
  worker:
    image: redash/redash:latest
    command: worker
    deploy:
      resources:
        limits:
          memory: 1.5G
        reservations:
          memory: 512M
    environment:
      QUEUES: "queries,scheduled_queries"
      WORKERS_COUNT: 2

  worker_heavy:
    image: redash/redash:latest
    command: worker
    deploy:
      resources:
        limits:
          memory: 3G
    environment:
      QUEUES: "clickhouse_heavy"
      WORKERS_COUNT: 1

Лимит memory: 3G для тяжёлой очереди — это не про экономию, а про предсказуемость: лучше пусть упадёт и перезапустится один воркер под конкретный тяжёлый запрос, чем OOM Killer положит весь хост вместе с server и postgres.

Своп как страховка, а не как рабочая память

Для Redash своп стоит держать включённым, но рассматривать его именно как аварийную подушку против редких пиков, а не как способ сэкономить на RAM:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

# Снижаем агрессивность подкачки — своп только когда реально припёрло
sudo sysctl vm.swappiness=10
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf

Если воркер регулярно уходит в своп при обработке обычных, не аномально тяжёлых запросов — это сигнал не «добавить своп побольше», а увеличить RAM или включить REDASH_ROW_LIMIT пожёстче.

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

Отдельно стоит учитывать саму служебную Postgres-базу Redash — ту, где хранятся сохранённые запросы, история выполнения, права доступа и результаты (Redash по умолчанию кеширует результаты запросов прямо в этой базе, в таблице query_results). При активном использовании и большом числе сохранённых запросов эта таблица может разрастаться на гигабайты, и Postgres будет просить под неё больше shared_buffers.

# postgresql.conf — для инсталляции с 8 ГБ общей RAM на сервере
shared_buffers = 512MB
effective_cache_size = 1536MB
work_mem = 16MB
maintenance_work_mem = 128MB

Если у вас уже есть отдельный проект по выбору аналитической СУБД под сами данные (не под метабазу Redash) — процесс выбора между ClickHouse и Postgres для больших объёмов подробно разобран в статье ClickHouse или PostgreSQL для аналитики. Сам Redash одинаково хорошо коннектится к обоим — вопрос выбора СУБД к его RAM-бюджету прямого отношения не имеет, кроме одного нюанса: ClickHouse умеет отдавать огромные результаты очень быстро, и без REDASH_ROW_LIMIT воркер захлебнётся именно на связке с ClickHouse чаще, чем с обычным Postgres.

Практическая конфигурация сервера

Сводим всё в конкретные рекомендации по железу:

Для установки самого Redash за прокси с HTTPS понадобится обратный прокси — если ещё не настраивали его для Docker-стека, посмотрите Traefik как reverse proxy для Docker и установку Let's Encrypt SSL на VPS — оба подхода закрывают Redash по HTTPS без лишней возни с ручными сертификатами.

Если вы ещё выбираете между Redash и альтернативами — учтите, что Metabase часто требует меньше памяти на старте (одно Java-приложение вместо пяти контейнеров), но менее гибок в SQL-запросах и шаринге между командами. Сравнение конкретных шагов установки есть в статье про установку Metabase на VPS — полезно прочитать перед выбором, если вы ещё не привязаны к Redash жёстко.

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