Сколько RAM нужно для Jitsi Meet

MAATRIX

Jitsi Meet выглядит как одна страница видеозвонка, но за ней стоит связка из пяти сервисов, и память они едят по-разному: одни — десятки мегабайт, другие — гигабайты на пике нагрузки. Если взять «стандартный» VPS на 2 ГБ и запустить на нём self-hosted Jitsi для команды из 15 человек, сервер начнёт свопиться в первую же конференцию с включёнными камерами. Разберём, из чего складывается потребление памяти и сколько реально закладывать под ваш сценарий — от личных созвонов до постоянно работающего сервера с записью.

Из чего состоит Jitsi Meet и куда уходит память

Классическая установка через docker-jitsi-meet — это не один контейнер, а стек из нескольких:

• jitsi/web — nginx, отдаёт статику фронтенда и проксирует запросы. Потребление минимальное, обычно укладывается в 50–100 МБ.
• jitsi/prosody — XMPP-сервер на Lua, через него участники обмениваются сигнальными сообщениями (кто в комнате, чат, поднятая рука). Лёгкий сервис, десятки мегабайт даже под нагрузкой.
• jitsi/jicofo (Jitsi Conference Focus) — Java-процесс, управляет распределением ролей и медиапотоков в конференции. Память умеренная, обычно несколько сотен мегабайт на JVM-кучу.
• jitsi/jvb (Jitsi Videobridge) — тоже Java, но это главный потребитель ресурсов в стеке. JVB — это SFU (Selective Forwarding Unit): он не микширует видео, а ретранслирует RTP-потоки между участниками. Каждый активный поток — это буферы, состояние сессии и накладные расходы JVM, поэтому память растёт почти линейно с числом одновременных видеопотоков.
• jitsi/jibri (опционально) — запись и трансляция. Это не облегчённый воркер, а headless Chrome плюс ffmpeg плюс виртуальный X-сервер: по требованиям к памяти и CPU ближе к десктопному браузеру, чем к серверному процессу.

Ключевой момент: до третьего участника в комнате Jitsi Meet по умолчанию работает в режиме P2P (peer-to-peer) — медиапотоки идут напрямую между браузерами, JVB вообще не задействован. Как только в комнате появляется третий человек, сервер переключает всех на JVB. Это значит, что тестовый звонок 1:1 почти ничего не скажет о поведении сервера в реальной групповой конференции.

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

Цифры ниже — не измеренный бенчмарк, а инженерная оценка на основе архитектуры (сколько памяти типично уходит на JVM-кучу JVB и jicofo плюс запас на ОС и буферы ОС для сетевого стека). У вас может выйти иначе в зависимости от того, сколько участников включают видео одновременно, какое разрешение используют и включён ли simulcast. Ориентируйтесь на них как на стартовую точку, а не как на гарантию.

Важный нюанс: рост числа участников не линеен по нагрузке, если включён Last N (по умолчанию сервер показывает видео только N последних активных говорящих, остальные идут без видео) и simulcast (клиент отправляет несколько версий потока в разном разрешении, JVB раздаёт нужную каждому получателю). Конференция на 50 человек с channelLastN: 20 нагружает JVB заметно меньше, чем если бы видео получали все 50×50 связей.

Videobridge — точка, где действительно кончается память

JVB — это JVM-процесс, и как у любой Java-программы, у него есть ограничение на кучу через флаг -Xmx. В образе jitsi/jvb это управляется переменной окружения JVB_HEAP_SIZE в файле .env вашего docker-jitsi-meet:

# .env
JVB_HEAP_SIZE=2048m

Если не задать значение явно, JVM выберет его сама на основе доступной памяти контейнера — и на маленьком VPS это может оказаться меньше, чем нужно под пиковую нагрузку, а на большом сервере JVM может отъесть больше, чем вы рассчитывали, оставив мало места под ОС и остальные контейнеры. Правило простое: на выделенном под Jitsi сервере задавайте JVB_HEAP_SIZE явно, не полагайтесь на автоопределение.

Проверить фактическое потребление можно двумя способами:

# память по контейнерам в реальном времени
docker stats --no-stream

# память системы целиком
free -h

У самого JVB есть встроенный REST-интерфейс со статистикой (по умолчанию порт 8080 внутри контейнера, эндпоинт /colibri/stats) — там видно число активных конференций, участников и потоков, что полезно сопоставлять с потреблением памяти при подборе JVB_HEAP_SIZE.

Jibri — отдельная история по памяти

Если вам нужна запись встреч или трансляция в YouTube/RTMP, учитывайте, что Jibri — это не «ещё один контейнер», а полноценная браузерная сессия: Xorg-дисплей, Chrome, который рендерит страницу конференции как обычный пользователь, и ffmpeg, кодирующий результат в файл или поток. Разработчики Jitsi прямо рекомендуют выносить Jibri на отдельную виртуальную машину, а не запускать его на том же сервере, что и JVB — они конкурируют за CPU и память в моменты пиковой нагрузки, и деградация записи (пропуски кадров) обычно первой сигнализирует о нехватке ресурсов.

Практический ориентир: закладывайте от 4 ГБ RAM на сервер Jibri при одной параллельной записи и добавляйте память кратно числу одновременных записей — каждая дополнительная запись это ещё один Chrome-процесс. Для команд, которым запись нужна нечасто, разумнее держать Jibri выключенным по умолчанию и поднимать сервис по запросу, чем резервировать под него память постоянно.

Практическая конфигурация: с чего начать

Для небольшой команды без Jibri стартовая конфигурация на выделенном или облачном сервере:

CPU: 4 vCPU
RAM: 8 ГБ
Диск: 40 ГБ SSD (логи + временные файлы, видео Jitsi не хранит)
Сеть: важна исходящая полоса — на каждого участника с видео уходит примерно 1–3 Мбит/с в обе стороны, считайте по своей типичной комнате

Пример фрагмента .env для docker-jitsi-meet с явными ограничениями памяти:

JVB_HEAP_SIZE=2048m
# jicofo не имеет отдельной переменной кучи в стандартном .env —
# при необходимости переопределите JAVA_OPTS в docker-compose.yml для сервиса jicofo

И ограничение памяти на уровне Docker, чтобы один контейнер не мог утащить память у соседей при аномалии:

services:
  jvb:
    deploy:
      resources:
        limits:
          memory: 2560M

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

Мониторинг, тюнинг и что делать при нехватке памяти

Прежде чем добавлять RAM, есть несколько бесплатных рычагов на стороне конфигурации:

• Ограничьте Last N. В config.js фронтенда параметр channelLastN задаёт, сколько видеопотоков сервер реально пересылает каждому участнику. Значение 20 вместо -1 (без ограничений) сильно снижает нагрузку на JVB в больших комнатах.
• Снизьте разрешение по умолчанию. Параметры constraints.video.height.ideal и .max в config.js управляют тем, какое разрешение запрашивает клиент. 720p по умолчанию вместо 1080p ощутимо снижает нагрузку на кодирование и объём трафика через JVB.
• Проверьте, не упирается ли конференция в CPU раньше, чем в память. JVB перекодированием не занимается (он именно пересылает потоки), но обработка RTP, шифрование DTLS-SRTP и сетевой стек всё равно нагружают процессор. Если docker stats показывает CPU у контейнера jvb на 90%+ при свободной памяти — узкое место не RAM, добавление ОЗУ здесь не поможет.
• Настройте swap как страховку, а не как рабочий режим. JVM-процессы не любят активный своппинг (резкие паузы на garbage collection), но небольшой swap на выделенном сервере спасает от OOM-killer в момент неожиданного всплеска. Общие подходы к диагностике нехватки памяти на сервере разобраны в статье что делать при нехватке RAM.
• Следите за лимитами контейнеров отдельно от лимитов JVM. Если у контейнера jvb есть Docker-лимит по памяти, а -Xmx в JVM_HEAP_SIZE выставлен близко к этому лимиту или выше него — контейнер может быть убит OOM-killer'ом ещё до того, как сама JVM решит, что памяти не хватает. Про баланс между лимитами контейнера и потреблением процессов внутри — в материале лимиты CPU и памяти в Docker.

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

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