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

MAATRIX

Saleor — не монолитный «магазин из коробки», а набор из нескольких сервисов: GraphQL API на Django, воркеры Celery, Redis, PostgreSQL и отдельно — дашборд и витрина. Поэтому вопрос «сколько RAM нужно для Saleor» не имеет одного числа-ответа: 2 ГБ хватит, чтобы просто запустить платформу и посмотреть на неё, а под реальный каталог на 10 000 товаров с нагрузкой уже нужен совсем другой расчёт. Разберём по компонентам, чтобы вы сами прикинули цифру под свой проект.

Из чего состоит Saleor и почему это влияет на RAM

Официальный self-hosted стек Saleor — это минимум четыре независимых процесса, и каждый ест память по-своему:

• Saleor Core — Django-приложение, отдающее GraphQL API. Запускается через ASGI-сервер (обычно uvicorn или daphne), в проде — несколько воркер-процессов за gunicorn.
• Celery worker(-ы) — асинхронные задачи: отправка email, синхронизация с внешними системами через вебхуки, обновление поисковых индексов, генерация превью изображений, обработка платежей.
• Celery beat — планировщик периодических задач (лёгкий, но обязательный отдельный процесс).
• PostgreSQL — основное хранилище: каталог, заказы, пользователи, атрибуты вариантов.
• Redis — брокер для Celery и кеш GraphQL-запросов.
• Saleor Dashboard — админка на React, собирается в статику и раздаётся любым веб-сервером (nginx, Caddy) — почти не требует RAM в рантайме, только на этапе сборки.
• Storefront — витрина на Next.js, часто разворачивается отдельно (в том числе на Vercel), к базовому расчёту RAM для бэкенда прямого отношения не имеет.

Ключевой момент: Django-процессы под ASGI и Celery-воркеры — это не потоки внутри одного процесса, а отдельные ОС-процессы с собственным импортированным Python-рантаймом. Каждый такой процесс после старта уже занимает 150–300 МБ до того, как обработает хоть один запрос — это база Django + загруженные модели + graphene-схема GraphQL. Отсюда и растёт итоговая цифра.

Dev-стенд: минимум, чтобы просто запустить

Если задача — поднять Saleor локально или на дешёвом VPS для знакомства с платформой, ориентируйтесь на:

Суммарно выходит 2–3 ГБ — это нижняя граница, на которой платформа поднимется и будет отвечать на запросы, но без запаса на пиковую нагрузку, импорт большого каталога или параллельные запросы из дашборда. Для честного dev-окружения, где вы одновременно гоняете миграции, импортируете тестовые товары через manage.py populatedb и держите открытым дашборд, комфортнее закладывать 4 ГБ.

Если поднимаете всё через docker-compose из официального репозитория saleor/saleor-platform, добавьте лимиты сразу — без них Celery и Postgres при желании съедят всё, что есть в системе:

services:
  api:
    deploy:
      resources:
        limits:
          memory: 512M
  worker:
    deploy:
      resources:
        limits:
          memory: 512M
  db:
    deploy:
      resources:
        limits:
          memory: 512M
  redis:
    deploy:
      resources:
        limits:
          memory: 128M

Продакшен для небольшого-среднего магазина

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

Формула для Saleor Core: RAM_core ≈ workers × 250–350 МБ. Число ASGI-воркеров gunicorn обычно берут по классической формуле (2 × CPU) + 1, но для GraphQL-нагрузки с тяжёлыми резолверами часто ограничивают меньшим числом, чтобы не упереться в память раньше, чем в CPU.

Пример для сервера на 4 vCPU / 8 ГБ RAM:

Итого около 5.3 ГБ занято, из них честный запас под пики — оставшиеся 2.7 ГБ. На практике это значит, что 8 ГБ — комфортный минимум для боевого Saleor, а 4 ГБ будет работать нестабильно при любом всплеске (массовый импорт товаров, синхронизация вебхуков, отчётный период).

Если магазин небольшой (до пары тысяч SKU, до 10 одновременных пользователей в дашборде), можно ужаться до 6 ГБ, урезав число Celery-воркеров до одного и ограничив gunicorn двумя процессами — но это уже без запаса.

Celery — главный источник неожиданного роста памяти

В отличие от Core и Postgres, память под Celery предсказать сложнее всего, потому что она зависит не от каталога, а от типа задач. Отдельно стоит следить за:

• Вебхуки — Saleor рассылает события (создание заказа, изменение остатков, оплата) на внешние URL. Если приёмник медленный, задачи копятся в очереди Redis, а воркеры держат их в памяти дольше.
• Генерация превью изображений — через Pillow, разовые пики по 100–200 МБ на процесс при обработке крупных исходников.
• Индексация каталога для внешнего поиска (Elasticsearch/OpenSearch, если подключены) — тяжёлые batch-задачи.
• Memory leak в долгоживущих воркерах — известная особенность Celery с prefork-пулом: процессы, обрабатывающие тысячи задач подряд, могут постепенно раздуваться. Лечится ограничением worker_max_tasks_per_child.

Практическая настройка, которая экономит RAM без потери отказоустойчивости:

# settings.py / celery config
CELERY_WORKER_MAX_TASKS_PER_CHILD = 100
CELERY_WORKER_MAX_MEMORY_PER_CHILD = 300000  # в КБ, ~300 МБ — воркер перезапустится сам
CELERY_WORKER_CONCURRENCY = 2

Это не панацея — сборка мусора Python не мгновенная, и это ориентировочные значения, которые стоит подстроить под свой поток задач, но именно worker_max_memory_per_child чаще всего спасает от медленного «расползания» Celery-воркера за сутки-двое работы.

PostgreSQL и Redis: тюнинг под ограниченную RAM

PostgreSQL по умолчанию настроен очень консервативно (рассчитан на сервер с 128 МБ RAM образца 20-летней давности), поэтому даже на выделенных под Saleor 8 ГБ его стоит подкрутить. Базовые параметры в postgresql.conf:

shared_buffers = 2GB          # ~25% RAM сервера БД
effective_cache_size = 6GB    # ~75% RAM
work_mem = 32MB               # растёт с числом сложных сортировок в GraphQL-запросах
maintenance_work_mem = 512MB
max_connections = 100         # Saleor + Celery редко требуют больше

Если PostgreSQL стоит на том же сервере, что и Core с Celery, не отдавайте ему 25% буквально от общей RAM сервера — считайте от того объёма, который реально остаётся после Core/Celery. Подробнее про сам процесс настройки — в статье про тюнинг PostgreSQL.

Redis в связке с Saleor используется под две роли — брокер Celery и кеш GraphQL — и обычно не растёт бесконтрольно, но лимит на память полезно выставить явно, чтобы при переполнении Redis не начал вытеснять свежие задачи из очереди раньше времени:

maxmemory 256mb
maxmemory-policy noeviction

noeviction для очереди задач принципиален: с allkeys-lru Redis может удалить ещё не выполненную задачу Celery, если решит, что ему не хватает памяти под новые ключи — а это уже потеря заказа или вебхука. Подробный разбор установки и первичной настройки — в статье как установить и настроить Redis.

Когда пора масштабироваться вертикально или разносить сервисы

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

1. OOM killer убивает Celery worker или postgres — смотрите dmesg | grep -i oom и журнал systemd. Если видите там процессы Saleor — это не «настроить параметр», это нехватка физической памяти, актуальный разбор — в статье что делать при нехватке RAM.
2. Растёт p95 время ответа GraphQL API при том, что CPU не упирается в потолок — часто значит, что Postgres начал вытеснять горячие данные из shared_buffers и читает с диска.
3. Очередь Celery (redis-cli llen celery) стабильно растёт, а не колеблется около нуля — воркерам не хватает либо процессов, либо памяти на процесс.

Когда каталог перерастает несколько десятков тысяч товаров или трафик выходит за пару сотен одновременных пользователей, разумно развести PostgreSQL на отдельный сервер (это сразу снимает конкуренцию за RAM между БД и приложением) и добавить второй сервер под Celery-воркеры отдельно от Core. Это же архитектурное решение, что и в других тяжёлых self-hosted платформах — разбор общих принципов есть в статье про лимиты CPU и памяти в Docker.

Ориентировочная сетка по стадиям роста:

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

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