Сколько RAM нужно для Rocket.Chat

MAATRIX

Официальные требования Rocket.Chat выглядят обнадёживающе скромно — 1 ГБ RAM в минимальных системных требованиях. На практике сервер с одним гигабайтом падает в OOM в первые же сутки, как только к чату подключается больше двух-трёх человек одновременно. Разница в том, что документация считает голый процесс Node.js без MongoDB, без репликасета, без видеозвонков и без учёта того, как Node вообще управляет памятью. Ниже — из чего реально складывается расход и сколько закладывать под конкретную нагрузку.

Почему официальный минимум обманчив

Rocket.Chat — это не один процесс, а связка из двух тяжёлых компонентов: сервер на Node.js (сам мессенджер, real-time через WebSocket, обработка сообщений) и MongoDB (хранилище всех данных, обязательно с репликасетом даже для одного узла — это требование самого Rocket.Chat, без него не работают change streams, на которых построен real-time).

Официальная страница требований указывает 1 ГБ RAM и 1 vCPU как минимум, но в том же документе отдельной строкой стоит: MongoDB нужен как минимум replica set из одного узла, а Node.js процесс по умолчанию поднимает V8 heap до 1,5–2 ГБ, если явно не ограничить. То есть сама платформа рассчитывает на существенно больше, чем указано в шапке требований.

error: Rocket.Chat requires oplog / replica set to be enabled for the
Meteor server to work properly.

Эту ошибку получает почти каждый, кто ставит MongoDB «как есть» через apt install mongodb без инициализации репликасета — сервис просто не запустится или свалится в bulk-degraded режим без real-time обновлений.

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

Возьмём типичную установку: Rocket.Chat 6.x + MongoDB 6.0 на Ubuntu 24.04, команда из 15-20 человек, обычная переписка без звонков.

Итог для покоя — около 1 ГБ, под нагрузкой легко уходит за 2,5 ГБ. Это и есть разрыв между «1 ГБ в документации» и «падает при двух пользователях» — документация не считает MongoDB и репликасет отдельными строками, хотя без них Rocket.Chat не запустится вообще.

Проверить фактическое потребление на своей машине:

sudo apt install -y smem
sudo smem -t -k -P 'node|mongod|nginx' -c 'name pss rss'

PSS (Proportional Set Size) честнее RSS — он не дублирует разделяемые библиотеки между процессами, а MongoDB и Node.js их используют достаточно много.

MongoDB — главный потребитель памяти

WiredTiger, движок хранения MongoDB по умолчанию, забирает под свой internal cache половину доступной памяти минус 1 ГБ:

cache_size = max((RAM - 1GB) / 2, 256MB)

На сервере с 4 ГБ это 1,5 ГБ только под кеш страниц базы — и это до всего остального. На сервере с 2 ГБ формула даёт 512 МБ, что уже тесновато для базы с активной историей сообщений и вложениями.

Ограничить явно:

# /etc/mongod.conf
storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 0.5

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

Отдельно нужно учитывать рост базы: вложения (если не вынесены в S3-совместимое хранилище), полнотекстовый индекс сообщений и служебные коллекции real-time API. На 20 активных пользователей за полгода база обычно набирает 2-5 ГБ на диске — индексы должны помещаться в RAM для быстрого поиска, иначе текстовый поиск по истории начинает идти мимо индекса и заметно тормозить.

Node.js: heap-лимит, который никто не выставляет

По умолчанию V8 (движок Node.js) сам решает, сколько памяти брать под heap — обычно это около 1,5–2 ГБ на 64-битных системах, независимо от того, сколько реально нужно приложению. На сервере с 2 ГБ суммарной RAM это уже конфликт с MongoDB за одну и ту же память.

Ограничить явно через переменную окружения в unit-файле systemd:

# /etc/systemd/system/rocketchat.service
[Service]
Environment=NODE_OPTIONS="--max-old-space-size=768"

768 МБ — рабочее значение для команды до 20-30 человек. Занижать ниже 512 МБ не стоит: на пиках (массовая рассылка, экспорт истории канала, синхронизация с LDAP) процесс начинает часто запускать сборку мусора, что видно как подтормаживание интерфейса у всех одновременно, а при совсем жёстком лимите — падает с FATAL ERROR: Reached heap limit.

<--- Last few GCs --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

Если видите такую ошибку в journalctl -u rocketchat -n 50, это почти всегда либо слишком низкий --max-old-space-size, либо утечка через plugin/интеграцию, которая держит ссылки на объекты в памяти — стоит на время отключить сторонние приложения из Marketplace и посмотреть, повторяется ли рост.

Видеозвонки и файлы: что резко поднимает планку

Базовый чат — это одна нагрузка, включённые звонки и файлообмен — совсем другая.

Встроенные звонки через Jitsi — самая частая причина, по которой команда, спокойно жившая на 4 ГБ, начинает получать жалобы «чат тормозит во время созвона». Если звонки нужны регулярно и на несколько человек одновременно, разумнее вынести Jitsi на отдельный сервер — конкуренция за CPU и память с MongoDB на одной машине прямая.

Сколько закладывать: таблица по числу пользователей

Цифры — для связки Rocket.Chat 6.x + MongoDB 6.0 на Ubuntu 24.04, без выделенного Jitsi. Одновременно активны обычно 20-30% от общего числа аккаунтов — от этой доли и считайте пик.

Эти цифры — ориентир, не гарантия: реальное потребление зависит от числа ботов и интеграций из Marketplace и от того, как часто идёт экспорт истории каналов. Точные числа даёт только замер на своей нагрузке.

Рабочий конфиг под 2 ГБ

Схема: 2048 МБ минус 250 (система) минус 500 (MongoDB WiredTiger cache) минус 768 (Node heap) — около 500 МБ на запас под пики nginx и сборку мусора.

MongoDB:

# /etc/mongod.conf
storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 0.5
net:
  bindIp: 127.0.0.1
  port: 27017
replication:
  replSetName: rs0

После первого запуска обязательно инициализировать репликасет одной командой в mongosh:

rs.initiate({
  _id: "rs0",
  members: [{ _id: 0, host: "127.0.0.1:27017" }]
})

Rocket.Chat через systemd с ограниченным heap:

[Service]
Environment=MONGO_URL=mongodb://127.0.0.1:27017/rocketchat?replicaSet=rs0
Environment=NODE_OPTIONS="--max-old-space-size=768"
Environment=PORT=3000
Restart=always

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

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
sysctl vm.swappiness=10

С такими настройками команда до 10 человек без видеозвонков живёт стабильно; регулярный мониторинг через mongosh --eval "db.serverStatus().wiredTiger.cache" покажет, когда кеш начинает упираться в потолок и пора расширять тариф.

Rocket.Chat vs Mattermost: разница в требованиях к железу

Если вы выбираете между self-hosted мессенджерами, стоит сразу понимать разницу в архитектуре и, соответственно, в аппетите к памяти. Подробный разбор установки альтернативы — в статье Mattermost на Ubuntu 24.04: пошаговая установка.

На сопоставимую нагрузку Mattermost обычно чуть экономнее по памяти за счёт PostgreSQL — у него нет обязательного репликасета и WiredTiger-кеша, растущего вместе с базой. Rocket.Chat взамен даёт более богатый набор интеграций и открытый API из коробки. Если стоит вопрос выбора базы данных под проект в целом, а не только под мессенджер, пригодится разбор MongoDB или PostgreSQL — что выбрать для сервера.

Какой сервер под Rocket.Chat взять в MAATRIX

Для теста и небольшой команды: 1 vCPU, 2 ГБ RAM, 20-30 ГБ NVMe. Здесь помещается команда до 10 человек без видеозвонков — с ограниченным NODE_OPTIONS и урезанным кешем MongoDB. Реальный минимум, а не формальный гигабайт из документации.

Комфортный вариант: 2 vCPU, 4 ГБ RAM, 40-80 ГБ NVMe. Подходит большинству небольших и средних команд — 15-30 человек, лёгкие звонки через облачный Jitsi, обычный набор интеграций из Marketplace. Второе ядро важно: MongoDB и Node.js — оба процессорозатратные под нагрузкой, и на одном ядре они конкурируют друг с другом даже при достаточной памяти.

Для растущей компании с self-hosted звонками: 4 vCPU, 8 ГБ, от 80-160 ГБ NVMe. Здесь MongoDB и Node получают собственный кеш без конфликтов, а Jitsi на том же сервере не роняет отзывчивость чата.

Локация. Rocket.Chat через WebSocket чувствителен к задержке — чем ближе сервер к пользователям, тем отзывчивее интерфейс и звонки. Для команды из России смотрите на локацию в РФ по минимальной задержке; для распределённой команды с участниками в Европе Лондон даёт компромисс по RTT.

MongoDB часто оказывается узким местом не по памяти, а по стабильности при неверной инициализации репликасета — если после установки видите ошибки в логах базы, пригодится разбор частых ошибок MongoDB на сервере. А общий подход к тому, сколько памяти закладывать с запасом на рост нагрузки, разобран в статье сколько оперативной памяти закладывать с запасом.

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