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

MAATRIX

В официальной документации Bagisto указано «минимум 2 GB RAM», и это правда работает — ровно до того момента, пока вы не подключите первого покупателя, не соберёте фронтенд через npm run production и не поставите Elasticsearch для поиска по каталогу. На практике память съедают не сам PHP-скрипт, а MySQL, очереди, кеш и (если он у вас есть) поисковый движок — вместе они легко удваивают-утраивают заявленный минимум. Ниже — конкретные цифры по сценариям: от локального теста до магазина на несколько тысяч SKU с Elasticsearch, плюс настройки PHP-FPM и MySQL под каждый вариант.

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

Bagisto — это Laravel-приложение (сейчас актуальны сборки на Laravel 10/11), а не монолит вроде Magento с собственным рантаймом. Память расходуется на четыре независимых компонента, и каждый живёт своей жизнью:

• PHP-FPM — сам код Bagisto, Blade-шаблоны, обработка запросов. Один воркер под реальной нагрузкой (с загруженными Eloquent-моделями, событиями, middleware) занимает 40-80 MB в зависимости от страницы — карточка товара тяжелее списка категорий.
• MySQL/MariaDB — каталог, заказы, атрибуты товаров (в Bagisto они EAV-подобные, как в Magento, что означает больше JOIN'ов и больше пользы от innodb_buffer_pool_size).
• Redis — кеш, очереди (QUEUE_CONNECTION=redis), сессии. Без Redis всё это падает на файловую систему или на ту же MySQL, что медленнее, но не требует отдельной памяти под сервис.
• Elasticsearch (опционально, через официальный пакет bagisto/elastic) — если вы включаете полнотекстовый поиск по каталогу, это отдельный JVM-процесс с собственной кучей, и он один способен съесть больше, чем всё остальное вместе взятое.

Плюс разовый пик при composer install и npm run production — сборка Vite/Webpack фронтенда может кратковременно требовать 1-1.5 GB, даже если в рантайме приложению хватает вдвое меньшего.

Минимальная конфигурация: тест и разработка

Для локальной разработки или демо-стенда без реального трафика Bagisto действительно запускается на 2 GB RAM — но с оговорками:

На 2 GB без свопа сборка фронтенда (npm run production) с высокой вероятностью упадёт по OOM — Node.js под Vite легко берёт 800 MB-1.2 GB на пике. Если своп не настроен, ядро просто убьёт процесс сборки. Как правильно посчитать и включить своп — отдельная тема, разобрана в статье про размер swap для VPS.

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

Продакшн: три реалистичных сценария по размеру магазина

Официальные требования Bagisto не разделяют «маленький» и «большой» магазин — а разница по RAM между ними двукратная и больше. Ориентировочная раскладка (без гарантии, что у вас будет ровно так же — зависит от количества атрибутов на товар, глубины категорий и трафика):

Маленький магазин — до 1000 SKU, до 50-100 заказов в день, без Elasticsearch (используется встроенный поиск по MySQL через LIKE/полнотекстовые индексы):

• RAM: 4 GB
• vCPU: 2
• MySQL innodb_buffer_pool_size: 512 MB-1 GB
• PHP-FPM: 6-8 воркеров (pm.max_children)

Средний магазин — 1000-5000 SKU, растущий трафик, Redis под кеш и очереди обязателен, Elasticsearch опционален:

• RAM: 8 GB
• vCPU: 4
• MySQL innodb_buffer_pool_size: 2 GB
• PHP-FPM: 12-16 воркеров
• Elasticsearch heap (если есть): 1-1.5 GB

Крупный магазин — 5000+ SKU, множество атрибутов и вариаций, Elasticsearch практически необходим, иначе поиск и фильтры по каталогу начинают тормозить на EAV-запросах:

• RAM: 16 GB
• vCPU: 6-8
• MySQL innodb_buffer_pool_size: 4-6 GB
• PHP-FPM: 20-30 воркеров
• Elasticsearch heap: 2-4 GB, лучше на отдельном сервере при активном росте

Это ориентиры, а не жёсткие пороги — реальное потребление зависит от того, сколько кастомных атрибутов у товаров (каждый — дополнительный JOIN в EAV-модели Bagisto) и насколько активно используются пользовательские сессии (гостевые корзины в Redis тоже занимают память, хоть и немного).

PHP-FPM: сколько воркеров реально нужно

Формула для pm.max_children стандартная: (доступная RAM для PHP) / (средний размер процесса). Для Bagisto под реальной нагрузкой закладывайте 60-80 MB на воркер, а не «типичные» 30-40 MB для лёгкого Laravel-API — за счёт Blade-рендеринга и загрузки моделей товаров с атрибутами процессы тяжелее.

Пример для сервера с 8 GB RAM, где под MySQL уже зарезервировано 2 GB, под Elasticsearch — 1.5 GB, под систему и Redis — ещё ~1 GB. На PHP остаётся примерно 3.5 GB:

; /etc/php/8.2/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 45
pm.start_servers = 10
pm.min_spare_servers = 8
pm.max_spare_servers = 20
pm.max_requests = 500

pm.max_requests = 500 важен отдельно — Laravel-приложения со временем накапливают утечки памяти в долгоживущих воркерах (особенно если используются очереди через тот же пул), периодический рестарт воркера после 500 запросов держит потребление стабильным.

Проверить фактическое потребление после нагрузки:

ps --no-headers -o "rss,cmd" -C php-fpm8.2 | awk '{ sum+=$1 } END { print sum/1024 " MB" }'

Если сумма стабильно упирается в лимит RAM — либо уменьшайте pm.max_children, либо переезжайте на тариф с большей памятью.

MySQL под EAV-модель Bagisto

Атрибуты товаров в Bagisto хранятся по EAV-схеме (как в Magento) — это значит, что даже простой листинг категории с фильтрами превращается в запрос с несколькими JOIN'ами по таблицам product_attribute_values. Для такой нагрузки innodb_buffer_pool_size важнее, чем для типичного CMS-сайта:

# /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld]
innodb_buffer_pool_size = 2G      # для сценария "средний магазин" на 8 GB RAM
innodb_buffer_pool_instances = 2
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 2
max_connections = 100

innodb_flush_log_at_trx_commit = 2 — компромисс: чуть менее строгая durability при падении сервера (можно потерять последнюю секунду транзакций), зато заметно меньше нагрузка на диск при частых операциях с корзиной и заказами. Для магазина с реальными платежами трезво взвесьте этот риск — если для вас критичен каждый заказ без исключений, оставляйте 1.

Если сервер тесный по памяти и MySQL приходится ужимать, у нас есть отдельный разбор оптимизации MySQL под 1 GB RAM — принципы применимы и к более крупным, но стеснённым в ресурсах конфигурациям.

Redis: экономит память или нет

Частый вопрос — не станет ли Redis лишней тратой RAM поверх MySQL. На практике наоборот: Redis для кеша и очередей обычно экономит совокупную память, потому что снимает нагрузку с MySQL (меньше повторных запросов к каталогу) и с диска (сессии и очереди не пишутся файлами).

В .env Bagisto достаточно переключить драйверы:

CACHE_DRIVER=redis
SESSION_DRIVER=redis
QUEUE_CONNECTION=redis
REDIS_HOST=127.0.0.1
REDIS_PORT=6379

Сам Redis-инстанс под Bagisto среднего размера обычно укладывается в 200-400 MB при разумном maxmemory и политике вытеснения allkeys-lru — это на порядок меньше, чем экономия на стороне MySQL за счёт кеша запросов и представлений категорий. Базовую установку и типовые проблемы (не хватает памяти, соединения обрываются) разбирали в статье про настройку Redis на VPS.

Держите maxmemory явно заданным — без лимита Redis попробует занять всю доступную память и рано или поздно столкнётся с OOM killer, что для очередей заказов означает потерянные джобы:

maxmemory 400mb
maxmemory-policy allkeys-lru

Elasticsearch: главный потребитель памяти в крупных магазинах

Если вы подключаете полнотекстовый поиск и фасетную фильтрацию через bagisto/elastic, готовьтесь, что Elasticsearch — самый прожорливый компонент стека. JVM-куче нужно закладывать отдельно, и она не должна превышать 50% доступной RAM хоста (правило самого Elasticsearch, оставшуюся половину использует файловый кеш ОС):

# /etc/elasticsearch/jvm.options.d/heap.options
-Xms1g
-Xmx1g

Для 4 GB RAM, целиком выделенных под индекс каталога, куча в 1 GB — разумный минимум; для каталога с 5000+ SKU и активными агрегациями по фильтрам закладывайте 2 GB кучи и выше. Общие принципы подбора памяти под Elasticsearch — в статье сколько RAM нужно для Elasticsearch, они применимы к индексу Bagisto без изменений.

Если каталог небольшой (до 500-1000 SKU) и фильтров немного, честный совет — не подключайте Elasticsearch вообще. Встроенный поиск Bagisto по MySQL с полнотекстовыми индексами на этом объёме работает приемлемо, а вы экономите гигабайт-два RAM и целый сервис, который нужно поддерживать и обновлять отдельно.

Кстати, если вы сравниваете Bagisto с другими open-source e-commerce на схожем стеке, у нас есть разбор требований для Medusa — другой архитектурный подход (headless на Node.js), но полезно для сравнения профилей потребления.

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