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

MAATRIX

Medusa — headless-платформа для интернет-магазина: бэкенд на Node.js отдаёт API, а фронтенд вы верстаете сами (обычно на Next.js) и полностью контролируете витрину. Проблема в том, что официальная документация даёт минимальные требования «для запуска», а не ответ на вопрос «выдержит ли это каталог на 5000 товаров и сотню заказов в день». Разберём, из чего складывается память Medusa на практике и как не промахнуться с тарифом сервера.

Из чего состоит память Medusa

Medusa — это не один процесс, а связка из нескольких компонентов, и считать память нужно по каждому отдельно, а не «на глазок по всей системе».

Ядро — Node.js-процесс самого Medusa-приложения: API-сервер, движок workflows (Medusa v2 построена на модульной архитектуре с оркестрацией через workflows), встроенная админка (React-приложение, которое либо собирается и раздаётся тем же процессом, либо билдится отдельно). Это классический V8-процесс: у него есть heap с настраиваемым лимитом (--max-old-space-size), и по умолчанию Node.js на 64-битных системах выделяет под old space до нескольких гигабайт — но реальное потребление обычно намного скромнее, если это не generation-heavy нагрузка вроде обработки больших CSV-импортов каталога.

Второй бюджет — PostgreSQL, основное хранилище Medusa (товары, заказы, клиенты, инвентарь, цены). Это отдельный процесс со своим потреблением RAM, полностью независимым от Node.js-процесса — на него уходит заметная часть бюджета сервера, особенно с ростом каталога.

Третий — Redis. В Medusa v2 Redis используется как event bus (события между модулями) и как backend для workflow-движка в production-режиме; также через него часто настраивают кэш сессий и очередь для тяжёлых задач. В dev-режиме Medusa может обойтись in-memory эмуляцией без Redis, но для продакшена Redis нужен обязательно — иначе события между модулями и восстановление workflows после падения процесса просто не будут работать надёжно.

Четвёртый, часто забываемый — сборка админки и статика: если вы собираете admin build на том же сервере (npx medusa build), сборка Vite на секунду-другую даёт заметный всплеск потребления памяти, который не отражает штатную нагрузку, но может уронить процесс на маленьком VPS, если своп не настроен.

Dev-режим и production: разница ощутимая

В dev-режиме (medusa develop) Node.js держит в памяти дополнительно: watcher файлов, source maps, HMR для админки, незакомпилированный TypeScript через ts-node/swc. На практике dev-процесс Medusa на пустой базе легко съедает 500 МБ – 1 ГБ уже в состоянии покоя, и это нормально — не повод для беспокойства, но и не показатель того, сколько нужно в проде.

В production-режиме (medusa start после medusa build) процесс работает с уже скомпилированным JS, без watcher и HMR — потребление ощутимо ниже и стабильнее, но добавляется постоянная нагрузка на память от реальных запросов: обработка изображений при загрузке, генерация PDF-накладных (если подключен такой плагин), синхронные вызовы к внешним платёжным и логистическим интеграциям, которые держат соединение открытым, пока ждут ответ.

Важный нюанс: если вы держите на одном сервере ещё и Next.js-витрину (storefront), это третий Node.js-процесс со своим бюджетом памяти, который часто недооценивают — витрину с SSR и ISR стоит закладывать отдельной строкой, а не считать, что «раз это тоже Node.js, влезет в тот же гигабайт».

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

Ниже — ориентировочные пороги, а не гарантия: реальное потребление зависит от числа установленных плагинов (платёжные шлюзы, доставка, поиск), сложности кастомных workflows и от того, стоит ли storefront на том же сервере.

Для честного теста «поднять и посмотреть» 2 ГБ хватит впритык, но это дев-режим на пустой базе. Как только вы начинаете реально наполнять каталог, подключать платёжные плагины и watch-процессы для кастомной разработки — комфортнее переходить на 4 ГБ. Если сомневаетесь между двумя строчками таблицы, берите план с запасом на шаг вверх: апгрейд VPS по памяти — вопрос минут, а разбирательство с падающим Node.js-процессом в разгар распродажи — нет.

PostgreSQL и Redis: отдельные бюджеты, не общий котёл

PostgreSQL под Medusa не требует экзотического тюнинга — это обычная реляционная база, но с ростом каталога и истории заказов её аппетит растёт заметнее, чем аппетит самого Node.js-процесса. Базовые ориентиры для настройки:

shared_buffers = 25% от RAM, выделенной под PostgreSQL
effective_cache_size = 50-75% от той же доли
work_mem = 4-16 МБ (осторожнее с параллельными сложными выборками по заказам/аналитике)
maintenance_work_mem = 256-512 МБ достаточно для типового магазина

Если PostgreSQL стоит на одном сервере с Medusa, не отдавайте ему теоретическую четверть от всей RAM сервера — считайте от факта, оставляя место под Node.js-процессы и Redis. Пошаговую установку и базовую конфигурацию смотрите в статье про установку PostgreSQL на VPS, а точную настройку shared_buffers и work_mem под конкретный объём RAM — в разборе тюнинга PostgreSQL.

Redis для Medusa обычно нетребователен по памяти в сценарии event bus и workflow-состояния — на типовом магазине это десятки-сотни мегабайт, если только вы не используете его же как полноценный кэш для тяжёлых списков товаров или сессий с большим TTL. Установка и базовая настройка — в статье про Redis на VPS; если Redis у вас неожиданно раздувается по памяти, отдельно разбирали типовые причины в статье Redis: высокое потребление памяти.

Держите оба процесса — PostgreSQL и Redis — под контролем лимитов независимо от Node.js: если один из них внезапно раздуется (например, PostgreSQL при неудачном VACUUM на большой таблице заказов), он не должен вытеснить из памяти сам API-сервер магазина.

Docker-развёртывание и лимиты памяти

Medusa часто разворачивают через docker-compose вместе с PostgreSQL и Redis — типовой каркас:

services:
  medusa:
    build: .
    mem_limit: 2g
    environment:
      - DATABASE_URL=postgres://medusa:medusa_pass@postgres:5432/medusa
      - REDIS_URL=redis://redis:6379
      - NODE_ENV=production
    ports:
      - "9000:9000"
    depends_on:
      - postgres
      - redis
  postgres:
    image: postgres:16
    mem_limit: 2g
    environment:
      - POSTGRES_USER=medusa
      - POSTGRES_PASSWORD=medusa_pass
      - POSTGRES_DB=medusa
    volumes:
      - pg-data:/var/lib/postgresql/data
  redis:
    image: redis:7-alpine
    mem_limit: 512m
    volumes:
      - redis-data:/data

Здесь легко ошибиться в двух местах. Во-первых, mem_limit для контейнера Medusa стоит считать не по среднему потреблению в покое, а по пиковому — импорт CSV на пару тысяч товаров или единовременная генерация большого количества PDF-накладных может кратковременно поднять потребление в разы, и если лимит выставлен впритык, cgroup OOM killer убьёт процесс жёстко, без штатной обработки ошибки. Во-вторых, сумма всех mem_limit в файле не должна вплотную подходить к RAM сервера — оставляйте запас под ОС, файловый кэш и всплески параллельно у нескольких сервисов сразу; общие принципы разбирали в статье про лимиты CPU и памяти в Docker.

Если вы дополнительно поднимаете storefront на Next.js в том же docker-compose, добавьте для него отдельный сервис с собственным mem_limit — не пытайтесь «сэкономить», разместив его в том же контейнере, что и backend: это разные процессы с разным жизненным циклом, и падение одного не должно ронять второй.

Как понять, что памяти не хватает

Нехватка RAM у Medusa редко выглядит как явная фатальная ошибка сразу — чаще это растущее время ответа API и периодические перезапуски контейнера:

# Общая картина по памяти и свопу
free -h

# Кто ест память прямо сейчас
htop

# Убивал ли ядро процессы по нехватке памяти
dmesg | grep -i "out of memory"
journalctl -k | grep -i "killed process"

# Для Docker — реальное потребление по контейнерам
docker stats --no-stream

# Внутри Node.js-процесса: heap usage
node -e "console.log(process.memoryUsage())"

Если в логах контейнера видите FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory — это V8 упёрся в лимит --max-old-space-size, и поднимать его вручную бессмысленно, если на сервере физически нет свободной RAM: сначала проверьте free -h, а уже потом решайте, увеличивать ли лимит heap или память сервера. Регулярные записи Killed process ... (node) в dmesg — прямой сигнал, что ядро останавливает процесс Medusa по нехватке физической памяти, а не какая-то ошибка в коде приложения.

Быстрые меры без апгрейда сервера: снизить одновременную нагрузку на импорт/экспорт (обрабатывать каталог батчами меньшего размера), проверить, не запущено ли параллельно несколько тяжёлых workflows (переиндексация, массовое обновление цен), ограничить work_mem PostgreSQL, если сложные выборки по заказам конкурируют за память с Node.js-процессом. Своп стоит держать как аварийную подушку на случай кратковременного пика, но не как постоянную опору — если Medusa регулярно уходит в своп, это сигнал брать план с большим объёмом RAM: диск на порядок медленнее RAM, и под свопом API-ответы витрины ощутимо тормозят прямо во время покупок. Подробнее о том, когда своп реально нужен и как его настроить — в статье когда нужен swap-файл.

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