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

MAATRIX

Directus — не совсем обычная CMS: вместо того чтобы диктовать свою схему базы данных, он подключается к уже существующей PostgreSQL, MySQL или SQLite и превращает её в REST/GraphQL API с админкой поверх. Это удобно, но именно поэтому вопрос «сколько RAM нужно» не имеет одного ответа — память ест не только сам Directus, но и интроспекция вашей схемы, кэш и соседняя база данных. Разберём, из чего складывается потребление и как не упереться в OOM на боевом сервере.

Что ест память в Directus

Directus — это Node.js-приложение (сейчас на базе Express/Fastify под капотом), которое при старте:

• поднимает сам процесс API-сервера;
• собирает и кэширует схему вашей базы данных — все таблицы, колонки, связи, права доступа по ролям;
• отдаёт статику админ-панели (собранное SPA-приложение, но это диск, не RAM);
• держит пул подключений к БД (DB_POOL__MIN/DB_POOL__MAX, по умолчанию небольшой пул);
• опционально кэширует ответы API в памяти или в Redis;
• обрабатывает загрузку и трансформацию файлов (ресайз изображений на лету — самая прожорливая операция по пикам RAM).

Базовый процесс без нагрузки на голом Node.js в среднем держится в районе 300-500 МБ резидентной памяти — это ориентир, не точное измерение, у вас может отличаться в зависимости от версии Node и количества установленных расширений (extensions/hooks). Дальше добавляются переменные слагаемые: размер схемы, количество одновременных запросов и то, включена ли обработка изображений внутри самого Directus.

Особенность Directus: работа поверх существующей БД без миграции

Если вы разворачиваете Directus поверх уже действующей продакшен-базы (типичный сценарий — «есть Postgres с 40 таблицами от старого бэкенда, хотим быстро получить админку и API без миграции данных»), это меняет расчёт памяти в двух местах:

1. Интроспекция схемы масштабируется от количества таблиц и колонок, а не от объёма данных. Directus строит внутреннее представление схемы (schema cache) при старте и при каждом изменении структуры. База на 500 МБ с 15 простыми таблицами съест меньше памяти на этом этапе, чем база на 50 МБ, но с 300 таблицами и сложными foreign key. Ориентируйтесь на количество коллекций и полей, не на размер БД в гигабайтах.
2. Сама СУБД — отдельный процесс, о котором часто забывают в расчётах. Если Postgres или MySQL живут на том же VPS, что и Directus, вам нужно закладывать RAM отдельно на shared_buffers/innodb_buffer_pool, а не рассчитывать, что «CMS уместится в те же 1 ГБ».

Плюс такого подхода — не нужно тратить память и время на этап миграции данных, как это бывает с CMS, которые требуют собственной схемы (Strapi, например, в этом смысле ближе — можно сравнить подходы в статье про установку Strapi на VPS). Минус — вы не контролируете структуру данных, и если унаследованная схема захламлена (сотни legacy-таблиц, которые Directus тоже будет пытаться проиндексировать), стоит ограничить видимость коллекций через права доступа и системную настройку schemaCache, чтобы не тащить в память всё подряд.

Сколько RAM нужно по сценариям

Ниже — ориентировочные цифры для типовых конфигураций. Это не бенчмарк, а практический диапазон «с чего начать», дальше смотрите на реальную нагрузку через мониторинг.

Важный нюанс: если БД уже работает на отдельном сервере (например, вы подключаете Directus к внешнему managed Postgres), из расчёта уходит целый столбец — тогда для самого Directus на небольшом и среднем проекте вполне хватает 1-2 ГБ. Если же вы совмещаете Directus, БД и Redis на одной VPS — закладывайте сумму, а не «примерно 1 ГБ на всё», это частая ошибка, которая потом выливается в постоянные рестарты по OOM.

docker-compose с лимитами памяти

Directus официально поставляется как Docker-образ, и разумно сразу выставить лимиты, чтобы один компонент не «съел» память соседних контейнеров при пиковой нагрузке:

version: "3.8"
services:
  database:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: directus
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_DB: directus
    volumes:
      - db_data:/var/lib/postgresql/data
    mem_limit: 2g
    mem_reservation: 512m

  cache:
    image: redis:7-alpine
    restart: unless-stopped
    mem_limit: 256m

  directus:
    image: directus/directus:11
    restart: unless-stopped
    ports:
      - "8055:8055"
    environment:
      KEY: ${DIRECTUS_KEY}
      SECRET: ${DIRECTUS_SECRET}
      DB_CLIENT: pg
      DB_HOST: database
      DB_PORT: 5432
      DB_DATABASE: directus
      DB_USER: directus
      DB_PASSWORD: ${DB_PASSWORD}
      CACHE_ENABLED: "true"
      CACHE_STORE: redis
      REDIS: redis://cache:6379
      DB_POOL__MIN: 2
      DB_POOL__MAX: 10
    depends_on:
      - database
      - cache
    volumes:
      - directus_uploads:/directus/uploads
    mem_limit: 2g
    mem_reservation: 768m

volumes:
  db_data:
  directus_uploads:

mem_limit — жёсткий потолок для контейнера (Docker убьёт процесс при выходе за него), mem_reservation — мягкий ориентир для планировщика. Для расчёта суммарного объёма VPS берите сумму mem_limit всех сервисов плюс 20-30% запаса на систему и файловый кэш ОС — подробнее про настройку лимитов в целом разобрано в статье про ресурсы и лимиты CPU/памяти в Docker.

Как снизить потребление RAM

Если сервер тесный или вы хотите выжать максимум из младшего тарифа, есть несколько рычагов:

• Вынесите обработку изображений за пределы Directus. Ресайз и трансформации на лету (?width=300&height=300) — самая тяжёлая по памяти операция при параллельных запросах. Если у вас высокая нагрузка на медиа, разумнее генерировать нужные размеры заранее или отдавать через внешний CDN/imgproxy, а Directus использовать только как источник оригиналов.
• Ограничьте пул подключений к БД. DB_POOL__MAX по умолчанию не безлимитный, но на слабом сервере имеет смысл держать его явно небольшим (5-10), иначе при всплеске запросов вырастет число одновременных соединений и, соответственно, память на стороне и Directus, и СУБД.
• Включите Redis для кэша вместо кэша в памяти процесса. Это не экономит RAM в сумме, но выносит переменную нагрузку в отдельный контейнер с предсказуемым лимитом, а не в основной процесс Directus, который иначе может расти непредсказуемо.
• Ограничьте видимость системных полей и коллекций. Через панель Settings → Data Model можно скрыть служебные/legacy-таблицы, которые Directus не должен индексировать в UI — это снижает объём schema cache в памяти на унаследованных базах.
• Отключите вебсокеты/realtime, если не используете. WEBSOCKETS_ENABLED: "false" в переменных окружения — если вам не нужны live-обновления в реальном времени, это лишний открытый канал и накладные расходы.
• Не забывайте про swap как страховку, а не основной ресурс. На VPS с 2 ГБ RAM разумный своп в 1-2 ГБ спасёт от мгновенного OOM-килла при кратковременном пике, но не должен использоваться как замена реальной памяти на постоянной основе — подробности в статье про настройку swap-файла.

Мониторинг и диагностика нехватки памяти

Прежде чем гадать, сколько RAM докупать, посмотрите на реальное потребление:

# потребление по контейнерам в реальном времени
docker stats

# лог событий OOM killer в системе
dmesg -T | grep -i "out of memory"

# память конкретного процесса Directus (если без Docker)
ps aux | grep directus | awk '{print $4, $6/1024 "MB", $11}'

Если видите, что directus регулярно растёт до потолка mem_limit и контейнер перезапускается — это почти всегда один из трёх сценариев: пиковая нагрузка на трансформацию изображений, слишком большой пул соединений к БД или утечка в кастомном хуке/расширении (extension), если вы что-то дописывали сами. Первым делом проверьте логи на паттерн частых рестартов именно вокруг запросов с ?width=/?height= — это самый частый источник внезапных скачков памяти в проде.

Если Directus стоит рядом с сайтом на том же сервере, полезно свериться с общими правилами расчёта памяти для веб-проектов — они разобраны в материале про то, что делать при нехватке RAM и в обзоре лучшего VPS для хостинга сайтов, если подбираете тариф с нуля.

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