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

MAATRIX

BigBlueButton — не просто видеозвонок, а связка из полудюжины сервисов: аудиомост, SFU для видео, доска, движок записи. Официальная документация называет минимум «8 ядер, 16 GB RAM» и почти не объясняет, откуда эта цифра берётся и когда её нужно поднимать. На практике сервер, который спокойно тянет один класс с включёнными камерами, начинает захлёбываться, стоит добавить breakout-комнаты или запустить запись. Разберём, из чего складывается потребление памяти в BBB и как посчитать сервер под свою нагрузку, а не подгонять под чужую вебинарную.

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

BigBlueButton — это не один процесс, а набор сервисов, которые общаются между собой и вместе формируют пользовательский опыт. Считать память нужно по каждому, иначе легко ошибиться в разы:

• FreeSWITCH — аудиомост для голоса всех участников. C-приложение, память растёт с числом одновременных аудиопотоков, но умеренно — голос дешевле видео.
• bbb-webrtc-sfu и mediasoup — сердце видео и демонстрации экрана. Mediasoup поднимает воркер-процессы (обычно по числу CPU-ядер), и именно эта связка отвечает за львиную долю CPU и RAM на сервере с активными вебкамерами.
• bbb-apps-akka — ядро логики встречи на JVM (Scala/Akka): состояние комнат, права участников, синхронизация действий. У JVM-приложений всегда есть немаленький базовый оверхед, не зависящий от числа участников, — это часть той самой «минимальной» цифры в 16 GB.
• Redis — обмен состоянием между сервисами и координация событий в реальном времени. Обычно лёгкий, но растёт с числом одновременных встреч и активностью чата.
• Etherpad — общий блокнот для заметок. Каждая встреча и каждая breakout-комната с открытой доской заметок — это отдельный pad, и их число размножается быстрее, чем кажется.
• nginx — отдаёт статику фронтенда и проксирует WebSocket-сигналинг, сам по себе почти не заметен в бюджете памяти.
• Обработка записи (ffmpeg-конвейер) — не работает постоянно, но даёт резкий всплеск CPU и RAM после завершения каждой встречи с включённой записью.

Если считаете память «на глаз», легко забыть, что JVM-часть и mediasoup-воркеры уже занимают заметный кусок сервера ещё до первого подключившегося участника — именно поэтому официальный минимум BBB не «от 2 GB», как у многих self-hosted сервисов, а сразу 16 GB.

Сколько RAM нужно по числу участников

Официальная рекомендация проекта — минимум 8 CPU-ядер и 16 GB RAM на выделенном (не сильно переподписанном) сервере, и это не «вилка для маленьких инсталляций», а стартовая точка, ниже которой сервисы начинают конкурировать за память даже при небольшой нагрузке. Дальше цифры растут вместе с числом одновременных участников и, что важнее, с долей тех, у кого включена камера.

Тестовая конфигурация на 8 GB технически запускается и годится, чтобы разобраться с установкой, но она ниже официального минимума — не полагайтесь на неё для реального занятия с включёнными камерами, доска и запись с высокой вероятностью начнут подтормаживать. Ориентир «150 участников на сервер» — не жёсткий лимит, а грубое правило из практики сообщества: у вас может быть заметно меньше, если большинство включает камеры и активно шарит экран, или больше, если это в основном слушатели с выключенным видео.

Ключевая оговорка: BigBlueButton считает нагрузку по одновременным участникам во всех активных встречах на сервере сразу, а не по числу зарегистрированных пользователей или курсов. Сервер на 16 GB, обслуживающий пять параллельных занятий по пять человек, нагружен примерно так же, как один класс на 25 человек.

Вебкамеры, доска и breakout-комнаты: что реально ест память

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

• Вебкамеры — самый дорогой ресурс. Аудио-поток дешёвый и для FreeSWITCH почти не заметен, а видеопоток через mediasoup требует декодирования/энкодирования и держит отдельное состояние на каждого. Занятие, где 20 из 25 участников включили камеру, нагружает сервер заметно сильнее, чем занятие на 25 человек с одной камерой преподавателя.
• Демонстрация экрана — по нагрузке сопоставима с ещё одной активной вебкамерой, особенно в высоком разрешении или с активным движением на экране (код, видео, анимация).
• Breakout-комнаты — это не «поделить одну встречу на группы бесплатно», а фактически несколько параллельных мини-встреч внутри одной: у каждой свой набор медиапотоков и, что часто упускают, свой Etherpad-документ для заметок. Разбив класс на 25 человек на пять breakout-комнат по пять, вы кратковременно получаете нагрузку, сравнимую с пятью отдельными небольшими встречами одновременно.
• Доска и опросы — сами по себе дешёвы по памяти, это в основном события в реальном времени через Redis, а не тяжёлые медиапотоки. Не закладывайте под них отдельный существенный бюджет.
• Общий чат и большая история сообщений — растёт медленно, но на длинных занятиях (несколько часов подряд) стоит держать в уме, что состояние встречи целиком живёт в памяти, пока встреча не закрыта.

Практический вывод: считайте не «участников», а «активных видеопотоков» — вебкамеры плюс шаринг экрана. Занятие с преобладанием аудио и текстового чата спокойно уложится в нижнюю границу диапазона из таблицы, а занятие, где включают камеры все и постоянно делят на breakout-группы, стоит планировать по верхней границе или сразу с запасом.

Установка и настройка: где крутить память руками

Стандартный путь установки — скрипт bbb-install.sh на чистый сервер с Ubuntu LTS той редакции, которую требует конкретная версия BBB (сверяйтесь с документацией перед установкой — требования по ОС меняются от релиза к релизу). Официально проект не тестируется в Docker: нужен прямой сетевой доступ без NAT-прослойки для WebRTC-сигналинга и ICE.

Базовая проверка сервера после установки:

sudo bbb-conf --check
sudo bbb-conf --status

bbb-conf --check выводит версии компонентов, статус systemd-юнитов и явно предупреждает, если сервер не укладывается в рекомендованные требования по CPU/RAM — не игнорируйте эти предупреждения.

Число воркер-процессов mediasoup, отвечающих за видео, задаётся в конфиге bbb-webrtc-sfu:

sudo nano /etc/bigbluebutton/bbb-webrtc-sfu/production.yml

mediasoup:
  numWorkers: 8   # по умолчанию обычно равно числу CPU-ядер

Поднимать numWorkers выше числа физических ядер бессмысленно — воркеры начнут конкурировать за CPU, а не добавлять пропускную способность, и заодно потянут больше RAM без пользы. После правки конфигов:

sudo systemctl restart bbb-webrtc-sfu
sudo bbb-conf --restart

Swap на сервере с BigBlueButton стоит держать небольшим и считать страховкой от внезапного OOM, а не рабочим резервом — аудио и видео чувствительны к задержкам, и как только FreeSWITCH или mediasoup уходят в своп, участники слышат это как рывки звука раньше, чем проблема появится в мониторинге. Ориентиры по размеру swap — в статье правильный размер swap для VPS.

Запись и обработка встреч — отдельный скачок нагрузки

Если запись включена, потребление ресурсов не заканчивается с завершением встречи. После выхода последнего участника BigBlueButton запускает конвейер обработки записи на ffmpeg: нарезка аудио/видео дорожек, превью слайдов и доски, сборка итогового плеера. Процесс идёт в фоне и может занять от нескольких минут до заметно больше на длинных встречах — в это время сервер нагружен сильнее, чем во время самой встречи, особенно по CPU, но и по RAM тоже.

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

Для сценариев с большим объёмом видео полезно заранее прикинуть, на сервере какого объёма памяти держать обработку и архив — общий разбор того, кому реально нужны серверы с большим RAM, есть в статье до 1 ТБ оперативной памяти в выделенном сервере — кому это реально нужно.

Мониторинг, нехватка памяти и когда пора масштабироваться

Базовый мониторинг памяти на сервере с BigBlueButton не отличается от любого Linux-сервера, но проверять его стоит чаще, чем на «спокойном» сервисе — из-за скачков при обработке записи и пиков во время занятий:

free -h
htop
docker stats --no-stream   # если часть окружения (Greenlight, Scalelite) вынесена в Docker
dmesg -T | grep -i "killed process"

Если dmesg показывает, что ядро убивало процессы по OOM во время занятия — это прямой сигнал, что текущей памяти не хватает даже на заявленную нагрузку, и поднимать сервер нужно сейчас, а не после следующего инцидента. Хуже всего, если OOM убивает FreeSWITCH или mediasoup прямо посреди встречи — участники получают обрыв связи без предупреждения.

Когда сервер начинает регулярно упираться даже после тюнинга — сигнал не наращивать память бесконечно, а масштабироваться горизонтально: несколько нод BigBlueButton за балансировщиком (в экосистеме проекта для этого обычно используют Scalelite), каждая в пределах разумных 16-32 GB, вместо одной гигантской машины.

Если специфичные для обучения функции — доска, breakout-комнаты, опросы — не нужны, а нужен просто надёжный групповой видеозвонок, часто проще и легче по ресурсам развернуть Jitsi Meet на VPS: архитектура похожая (тоже WebRTC-SFU), но компактнее по набору сервисов. Для сценария с оценками, расписанием и записями BBB остаётся более целостным решением, а для голоса и видео задержка сети до сервера влияет на качество не меньше RAM — если аудитория в одном регионе, выбирайте локацию под неё, обзор вариантов есть в статье VPS в России для мессенджеров и звонков.

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