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

MAATRIX

Flarum — один из немногих форумных движков, для которого вопрос «хватит ли RAM» звучит почти неуместно: это классический PHP-стек без тяжёлого рантайма и без ресурсоёмкой пересборки при каждом обновлении. Но «почти неуместно» не значит «неважно» — на маленьком VPS с 512 MB форум может стартовать и тут же упасть при первой попытке поставить расширение через Composer. Разберём, из чего реально складывается потребление памяти под Flarum и сколько закладывать под разные размеры сообщества.

Почему Flarum экономнее Discourse и других форумов

Flarum написан на PHP с использованием компонентов Laravel на бэкенде и Mithril.js на фронтенде — это принципиально другая архитектура, чем у Discourse на Ruby on Rails. Разница напрямую влияет на память:

• Нет процесса тяжёлой пересборки при обновлении. Discourse на каждый апдейт гоняет rebuild, который компилирует JS/CSS и кратковременно требует 1.5-2 GB RAM сверх обычной нагрузки. У Flarum обновление — это composer update плюс миграции базы, заметно легче по пиковому потреблению.
• Фронтенд — статичный SPA-бандл. Mithril.js собирается один раз (или ставится уже готовым через Composer-пакет) и отдаётся браузеру как обычный статический JS-файл. Сервер не рендерит HTML на каждый запрос, как это в разной степени делают Rails или, например, WordPress с тяжёлыми темами.
• Стандартный PHP-FPM стек. Это тот же тип нагрузки, что у большинства сайтов на PHP: воркеры PHP-FPM, MySQL/MariaDB, веб-сервер перед ними. Ничего экзотического, знакомая модель памяти, которую легко предсказать и подкрутить.

У Flarum, в отличие от Discourse, нет официальной таблицы «столько-то RAM на столько-то пользователей» — проект не публикует жёстких системных требований, кроме версии PHP и базы данных. Это одновременно и плюс (движок реально skромный), и минус (придётся считать самостоятельно, ориентируясь на компоненты стека, а не на цифру из документации).

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

На типичном сервере с Flarum память делят четыре потребителя:

• PHP-FPM воркеры — обрабатывают HTTP-запросы к форуму. Каждый воркер держит загруженное Laravel-ядро Flarum и активные расширения; по опыту эксплуатации похожих Laravel-приложений это порядка 30-60 MB на воркер, но конкретная цифра сильно зависит от количества и «тяжести» установленных расширений.
• MySQL или MariaDB — хранит темы, посты, пользователей. У маленького форума база крошечная и работает почти полностью из кэша ОС; у большого сообщества с историей в сотни тысяч постов буфер InnoDB начинает быть значимой статьёй расхода.
• OPcache — кэш скомпилированного байткода PHP. Без него каждый запрос заново парсит и компилирует PHP-файлы Flarum и всех расширений — это не про экономию памяти, а про то, что без OPcache форум будет заметно медленнее при той же RAM.
• Веб-сервер (nginx или Apache) — сам по себе лёгкий, обычно десятки мегабайт, если не считать буферы на аплоад файлов и вложений.

Отдельно стоит Composer — он не работает постоянно, но именно на нём чаще всего спотыкаются маленькие VPS: composer update при установке расширений может кратковременно требовать значительно больше памяти, чем сам работающий форум.

Сколько RAM нужно по размеру форума

Это ориентир на основе типового PHP-FPM/MySQL стека, а не официальная рекомендация Flarum — у проекта такой таблицы нет. Реальные цифры будут отличаться в зависимости от набора расширений (особенно тяжёлых — поиск по вложениям, интеграции с внешними сервисами) и от того, сколько параллельных пользователей одновременно открывают форум.

Для сравнения: Discourse на аналогичном по активности форуме официально просит от 8 GB для продакшна — Flarum на том же уровне нагрузки укладывается в 4-6 GB именно из-за более лёгкого рантайма. Это не значит, что Flarum «лучше» — Discourse даёт из коробки больше готовых функций (модерация, бейджи, полнотекстовый поиск с индексацией), и часть его накладных расходов — плата за это.

PHP-FPM: pm.max_children и типичные ошибки конфигурации

Самая частая причина, по которой Flarum «тормозит», хотя памяти вроде хватает — неправильно выставленный пул PHP-FPM. По умолчанию многие дистрибутивы ставят pm.max_children с запасом, который не соответствует реальному объёму RAM сервера, и под нагрузкой это либо душит форум нехваткой воркеров, либо роняет сервер по OOM, если воркеров слишком много.

Типичный конфиг пула для сервера с 2 GB RAM, где Flarum делит память с MySQL:

; /etc/php/8.x/fpm/pool.d/flarum.conf
[flarum]
user = www-data
group = www-data
listen = /run/php/php-flarum.sock

pm = dynamic
pm.max_children = 8
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 500

Логика расчёта простая: если один воркер в среднем занимает 40-50 MB, а под PHP-FPM выделено, скажем, 500 MB (остальное — MySQL, ОС, OPcache), то pm.max_children в районе 8-10 — разумный потолок, а не число «на глаз» из шаблонного конфига. Проверить реальное потребление воркеров:

ps --sort=-rss -eo rss,pid,cmd | grep php-fpm | head -10
systemctl status php8.x-fpm

Отдельно стоит включить и настроить OPcache — это не про RAM напрямую, но экономит CPU и снижает пиковые задержки, которые иначе маскируются под «нехватку памяти»:

; /etc/php/8.x/fpm/conf.d/10-opcache.ini
opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=10000
opcache.validate_timestamps=0

Последняя строка (validate_timestamps=0) даёт заметный прирост скорости, но требует ручного php flarum cache:clear после каждого обновления форума или расширений — иначе Flarum продолжит отдавать закэшированный старый код.

MySQL/MariaDB: буфер пула и куда уходит память

Для небольшого форума MySQL или MariaDB почти не заметны на фоне остальных процессов — база в десятки мегабайт целиком помещается в память и работает быстро при любых разумных настройках. Проблема начинает проявляться, когда форум растёт: полнотекстовый поиск, JOIN по таблицам постов и пользователей на десятках тысяч записей упираются в размер innodb_buffer_pool_size.

Ориентировочный конфиг для сервера с 4 GB RAM, где MySQL делит машину с Flarum:

[mysqld]
innodb_buffer_pool_size = 1G
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 1
max_connections = 50

Правило по буферу — держать его в районе 50-70% от памяти, которую вы готовы отдать под базу (не под весь сервер), и наращивать пропорционально росту количества постов, а не пользователей — именно объём данных, а не активность, определяет, насколько буфер должен быть больше базы, чтобы она работала преимущественно из RAM, а не с диска. Если ставите MariaDB с нуля, есть отдельный разбор установки MariaDB на VPS с базовыми шагами по конфигурации, а выбор между MySQL и MariaDB для форумной нагрузки — тема отдельной статьи про MariaDB или MySQL, если вы ещё не определились с движком базы.

Composer и установка расширений: где спотыкаются маленькие VPS

Это самая недооценённая ловушка для Flarum на бюджетном VPS. Сам форум под нагрузкой требует немного, но composer update при установке или обновлении расширений — совсем другая история: Composer держит в памяти дерево зависимостей всего проекта и на сервере с 512 MB — 1 GB может упасть с ошибкой нехватки памяти прямо посреди установки расширения.

Типичная ошибка, которую видит администратор форума на маленьком сервере:

Fatal error: Allowed memory size of 134217728 bytes exhausted

Стандартное решение — временно снять лимит памяти для самого Composer, это не увеличивает реальное потребление форума, только позволяет процессу установки завершиться:

COMPOSER_MEMORY_LIMIT=-1 composer update flarum/flarum "*" --with-all-dependencies

Если на сервере физически мало RAM и снятие лимита не помогает (процесс убивает уже сам OOM killer ядра, а не PHP), временный выход — добавить своп на время установки расширений:

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Это рабочий костыль именно на разовую операцию, а не постоянная замена RAM — держать боевую базу на свопе не стоит, задержки диска будут заметны на каждом запросе. Если сервер регулярно упирается в память не только на Composer, но и в обычном режиме, разумнее сразу смотреть в сторону апгрейда — общий разбор признаков и вариантов действий есть в статье что делать при нехватке RAM, а про грамотную настройку самого свопа — в статье своп-файл: когда нужен и как настроить.

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