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

MAATRIX

NodeBB — редкий случай форумного движка, где realtime не прикручен сбоку через плагин, а зашит в архитектуру: список тем обновляется без перезагрузки страницы, счётчик онлайн меняется на глазах, уведомления прилетают мгновенно. Расплата за это — память расходуется иначе, чем у классического PHP-форума вроде phpBB или Discourse на Rails: здесь один Node.js-процесс держит в оперативке не только код, но и живые WebSocket-соединения каждого открытого таба браузера. Разберём, из чего складывается потребление RAM у NodeBB и сколько закладывать под форум разного размера.

Из чего складывается память NodeBB

NodeBB — это связка из нескольких процессов, и память нужно считать по каждому:

• Node.js-процесс приложения — сам форум: рендеринг шаблонов, обработка API-запросов, бизнес-логика. Это основной потребитель, растёт с числом одновременных HTTP-запросов и активных WebSocket-сессий.
• База данных — NodeBB поддерживает Redis, MongoDB или PostgreSQL как основное хранилище. Выбор базы сильнее всего влияет на итоговую цифру RAM, об этом ниже отдельно.
• Redis как кеш и pub/sub — даже если основная БД не Redis, он часто нужен для сессий и синхронизации между несколькими инстансами NodeBB (кластер за балансировщиком).
• Nginx перед Node.js — раздача статики, TLS-терминация, проксирование WebSocket. Сам по себе съедает немного, десятки мегабайт.
• Обработка изображений — библиотека sharp для аватаров и превью, разово даёт всплески при загрузке файлов.

Для небольшого форума (до пары сотен активных пользователей в день) сумма всех компонентов укладывается в 1.5-2 ГБ. Дальше рост нелинейный: не сама база данных внезапно "тяжелеет", а количество открытых WebSocket-соединений и размер кеша БД растут вместе с трафиком.

Node.js-процесс и сборка мусора V8

Node.js по умолчанию ограничивает heap движка V8 — старое поведение было около 1.5-2 ГБ на процесс для старых major-версий Node без явных флагов, но на современных LTS (Node 20/22, которые официально поддерживает NodeBB на конец 2026 года) лимит по умолчанию считается от доступной физической памяти и обычно заметно выше. Тем не менее NodeBB под реальной нагрузкой — это не только heap-объекты JS, это ещё и native-память: буферы сокетов, зависимости вроде sharp (обёртка над libvips, память вне V8-кучи).

Если вы видите, что процесс node в htop стабильно растёт и не отдаёт память обратно ОС — это почти всегда нормальное поведение V8 (garbage collector не спешит возвращать страницы ядру), а не утечка. Разница между утечкой и штатным ростом видна по графику за несколько дней: утечка растёт монотонно даже ночью при нулевой нагрузке, штатное поведение выходит на плато и колеблется вместе с трафиком.

Полезный флаг для контроля пиков — ограничить старую кучу явно:

node --max-old-space-size=1024 app.js

Ставить это стоит только если сервер тесный по памяти и вы готовы отслеживать OOM-ошибки в логах — жёсткий лимит ниже реальной потребности приведёт к падению процесса под нагрузкой, а не к плавной деградации.

Для продакшена NodeBB рекомендует запуск через встроенный кластер-менеджер (./nodebb start в режиме нескольких воркеров) либо через PM2 с pm2 start app.js -i max — это создаёт по процессу на ядро CPU. Каждый воркер — это отдельное потребление памяти, поэтому кластеризация на 4 ядрах может ощутимо поднять суммарный расход RAM по сравнению с одним процессом, зато даёт устойчивость к падению одного воркера и параллельную обработку CPU-тяжёлых операций (те же превью изображений).

База данных: Redis, MongoDB или PostgreSQL

Это решение задаётся один раз при установке NodeBB и меняет профиль потребления памяти сильнее всего.

Redis. Хранит всё в оперативной памяти по определению — это его главное свойство и одновременно главный риск по RAM. На малых и средних форумах (до нескольких тысяч постов) это совсем немного, десятки-сотни мегабайт, потому что текстовые данные форума в сыром виде компактны. Но с ростом базы Redis не может "выгрузить холодные данные на диск" так, как это делает СУБД со своим buffer pool — весь датасет обязан помещаться в RAM (persistence через RDB/AOF — это про сохранность при рестарте, не про экономию памяти в рантайме). Для форума, который планируется растить годами, это стоит учитывать заранее.

MongoDB. Официально рекомендуемая база для NodeBB и, по опыту большинства инсталляций, наиболее сбалансированный вариант. WiredTiger (движок хранения MongoDB по умолчанию) сам управляет объёмом кеша и по умолчанию резервирует под него примерно половину доступной RAM за вычетом 1 ГБ — то есть на сервере с 4 ГБ памяти кеш займёт около 1.5 ГБ, если явно не ограничить. Это управляемо через параметр storage.wiredTiger.engineConfig.cacheSizeGB в mongod.conf — на тесном сервере кеш стоит подрезать вручную, иначе Mongo заберёт память, которая нужна Node.js-процессу.

PostgreSQL. Поддерживается NodeBB, но менее обкатан сообществом, чем Mongo. Управление памятью через shared_buffers — здесь ниже риск неожиданного разрастания, потому что Postgres исторически спроектирован под работу с ограниченными buffer pool и активно полагается на файловый кеш ОС, который освобождается под давлением памяти сам собой.

Практический вывод: если сервер тесный по памяти (1-2 ГБ), MongoDB с явно ограниченным кешем или PostgreSQL безопаснее, чем Redis как основное хранилище на растущем форуме. Подробно про настройку самой Mongo — в статье про установку MongoDB на VPS, про Redis — в отдельном разборе.

Realtime: сколько добавляют Socket.io-соединения

Вот чем NodeBB принципиально отличается от WordPress или Discourse (тот тоже realtime, но через Rails+Sidekiq, память считается иначе) по профилю потребления памяти: каждый открытый в браузере таб форума держит постоянное WebSocket-соединение к серверу. Это не запрос-ответ HTTP, который завершился и забылся — это живой объект в памяти Node.js-процесса на всё время, пока пользователь на странице.

Разовое соединение стоит немного — по опыту, порядка нескольких десятков-сотен килобайт с учётом буферов и служебных данных Socket.io на подключение, но точная цифра зависит от версии Socket.io, размера комнат (rooms), в которые подписан клиент, и от того, сколько событий форум транслирует в реальном времени. Важно другое: это линейный рост с числом одновременно открытых вкладок, а не с числом зарегистрированных пользователей. Форум с 10 000 зарегистрированных, но 50 одновременно активными — легче форума с 2 000 зарегистрированными, из которых 500 держат вкладку открытой (модераторы, которые сидят в форуме весь день, привычка держать вкладки).

Отсюда практическое правило: закладывайте память не под общее число пользователей, а под пиковое число одновременных соединений — его видно в админке NodeBB (Панель администратора → Панель управления → онлайн-пользователи) или через pm2 monit.

Обработка изображений и загрузка файлов

Аватары, превью вложений, ресайз картинок в постах — за это отвечает sharp, обёртка над библиотекой libvips на C. В штатном режиме простоя она почти ничего не ест, но при массовой загрузке (например, миграция форума с импортом тысяч старых аватаров) даёт короткие всплески памяти, пропорциональные размеру обрабатываемых изображений и числу параллельных задач.

Если форум ожидает активную загрузку пользовательских картинок (а на практике это почти любой живой форум), стоит:

• держать запас RAM сверх расчётной базовой линии — процентов 20-30 на пики, а не считать впритык;
• ограничить максимальный размер загружаемого файла в настройках NodeBB (Панель администратора → Настройки → Загрузки), чтобы один пользователь не мог одним запросом выбить сервер по памяти;
• при кластерном запуске (несколько воркеров NodeBB) пики от разных пользователей размазываются по разным процессам, что снижает риск, что один "тяжёлый" аплоад заденет всех.

Для форумов с активным медиаконтентом (скриншоты, фото) полезно вынести раздачу уже обработанных файлов через nginx или CDN, не гоняя их через Node.js повторно — это не столько экономит память, сколько снимает лишнюю нагрузку с event loop.

Сколько RAM нужно на практике: таблица по масштабу

Ориентировочные цифры для конфигурации Node.js + MongoDB + Redis (сессии/кеш) + Nginx на одном сервере, без внешних факторов вроде агрессивного антибот-трафика или частых миграций. Это ориентир по опыту типичных инсталляций, не гарантированное измерение — у вас будет отличаться в зависимости от плагинов, темы и объёма контента.

На старте закладывайте с запасом на один шаг вверх по таблице: миграция базы на более мощный сервер под живым форумом — не самая приятная операция (нужен даунтайм или репликация), а апгрейд VPS по ресурсам обычно занимает минуты. Если параллельно на том же сервере крутится что-то ещё — почта, второй сайт, мониторинг — добавляйте их потребление отдельно, NodeBB эти цифры не включает.

Как проверить реальное потребление и не гадать

Табличные ориентиры — это стартовая точка, а не замена измерению на вашем конкретном форуме. Проверить факт:

# память по процессам NodeBB и MongoDB
ps aux --sort=-%mem | grep -E 'node|mongod|redis' | head -10

# если запущено через PM2 — сводка по каждому воркеру
pm2 list
pm2 monit

# память MongoDB отдельно, включая WiredTiger cache
mongosh --eval "db.serverStatus().wiredTiger.cache"

Если свободная память на сервере регулярно уходит в ноль и включается swap — это первый сигнал, что текущего объёма RAM не хватает, а не повод сразу докупать ресурсы: сначала стоит проверить, не забыла ли MongoDB кеш не ограниченным (см. раздел про базы выше), и не накопилось ли на сервере лишних процессов. Про то, как быстро понять, действительно ли уперлись в память, есть отдельный разбор — что делать при нехватке RAM. Правильно настроенный swap на VPS — не решение проблемы нехватки RAM, а страховка от жёсткого падения по OOM, пока вы не увеличили ресурсы; как его посчитать — в статье про размер swap.

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

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