Голосовой сервер (TeamSpeak/Mumble) — сколько ресурсов нужно

MAATRIX GAMES

Заказываешь под голосовой сервер тот же тариф, что и под игровой — «на всякий случай», с запасом на 8 ГБ и четыре ядра — а потом видишь в панели, что used-память болтается на уровне 150 МБ, а CPU не поднимается выше 2%. Знакомая картина: TeamSpeak и Mumble устроены совсем не так, как Minecraft или Rust, и считать под них ресурсы по игровой методике — это переплатить за то, что никогда не будет использовано. Разберём, что реально ест голосовой сервер, а что — миф, доставшийся по инерции от игровых серверов.

Почему голосовой сервер — это не игровой сервер по нагрузке

Игровой сервер держит в памяти состояние целого мира: карту, позиции всех entity, инвентари, физику, — и пересчитывает это состояние на каждом тике, десятки раз в секунду. Голосовой сервер не делает почти ничего из этого. У него нет мира, нет тика, нет физики — есть только список подключённых клиентов, права доступа к каналам и поток аудиопакетов, который нужно принять от говорящего и раздать всем остальным в канале.

По сути и TeamSpeak 3, и Mumble (серверная часть которого называется Murmur) — это два относительно простых процесса:

• Диспетчер аудиопотоков. Принимает UDP-пакеты с закодированным звуком (оба используют кодек Opus) от говорящего клиента и рассылает их копии всем, кто должен их услышать. Кодирования на самом сервере почти нет — сервер не перекодирует поток, а просто ретранслирует уже сжатые Opus-пакеты, что и объясняет низкую нагрузку на CPU.
• База прав и структуры. SQLite-база (ts3server.sqlitedb у TeamSpeak, mumble-server.sqlite у Mumble) с каналами, группами, правами и списком зарегистрированных пользователей. Она нужна для авторизации при подключении и почти не трогается в рантайме, пока кто-то не меняет права или не создаёт канал.

Отсюда и вывод, который выбивается из привычной игровой интуиции: количество слотов на голосовом сервере почти не влияет на потребление CPU, а RAM растёт настолько плавно, что даже сотня одновременных пользователей укладывается в объём, которого не хватило бы даже для запуска пустого Minecraft-сервера. Подробно про то, откуда вообще берётся расход RAM у игровых серверов и почему там всё иначе — в статье про методику расчёта RAM под игровой сервер.

Сколько RAM и CPU реально нужно

Цифры ниже — по опыту эксплуатации похожих нагрузок и данным каталога games.maatrix.io, где для голосовых серверов уже заложены проверенные объёмы (TeamSpeak — 512 МБ, Mumble — 256 МБ базово). Точная нагрузка немного гуляет в зависимости от активности разговоров и того, включены ли файлообмен и аватарки:

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

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

Главная нагрузка — исходящий трафик, а не CPU или RAM

Вот тут кроется то, что реально стоит закладывать в расчёт, и о чём почти никогда не думают заранее. Голосовой сервер работает по модели «звезда»: каждый говорящий шлёт один поток на сервер, а сервер обязан разослать копию этого потока всем остальным подключённым клиентам. Это значит, что исходящий трафик растёт не линейно от числа пользователей, а от произведения «сколько человек говорят одновременно» на «скольким слушателям нужно доставить их голос».

Пример на пальцах (числа ориентировочные — точный битрейт зависит от настроек качества кодека Opus, которые задаются и в TeamSpeak, и в Mumble отдельным параметром, обычно в диапазоне 16-40 кбит/с на поток):

Исходящий трафик ≈ (число говорящих одновременно)
                  × (число остальных слушателей)
                  × битрейт одного потока

Возьмём сервер на 50 подключённых, из которых одновременно говорят 5 человек (например, несколько групп болтают в разных каналах разом), битрейт — 40 кбит/с на поток:

5 × 49 × 40 кбит/с ≈ 9800 кбит/с ≈ ~9.8 Мбит/с исходящего трафика

Для сравнения: RAM у такого сервера — сотни мегабайт, а канал в пике просит почти 10 Мбит/с непрерывно. Именно поэтому у Mumble в конфиге /etc/mumble-server.ini есть отдельный параметр bandwidth=72000 — это лимит битрейта на клиента в битах в секунду (по умолчанию 72 кбит/с), который сервер сам не даст превысить каждому отдельному потоку, чтобы не улететь в потолок канала при большом числе говорящих одновременно.

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

TeamSpeak vs Mumble: разница в ресурсах и лицензии

По железу оба варианта легковесны, но есть нюансы, которые стоит знать до выбора:

Если ключевой фактор — минимальный расход RAM и полная свобода от лицензионных лимитов слотов, Mumble выигрывает почти по всем пунктам, и именно поэтому в каталоге games.maatrix.io он самый нетребовательный к памяти голосовой сервер вообще. Если важнее привычный интерфейс, к которому уже приучено комьюнити, и файлообмен через клиент — TeamSpeak по-прежнему держится на 512 МБ, что тоже совершенно не тяжело. По железу разница между ними — это разница между «очень легко» и «ещё легче», а не «легко» и «требовательно». Пошаговая установка обоих разобрана отдельно: как поднять TeamSpeak и как поднять Mumble.

Что будет, если посадить голосовой сервер рядом с игровым

Раз голосовой сервер такой лёгкий, логичный вопрос — а зачем вообще под него отдельный тариф, если можно подселить его на тот же VPS, где уже крутится Rust или ARK? Ответ: можно, и по чистой арифметике RAM/CPU это почти незаметно — TeamSpeak на 512 МБ рядом с Rust-сервером на 8 ГБ не создаст дефицита памяти. Но есть три момента, за которыми стоит следить:

• Порты не должны пересекаться. У TeamSpeak это 9987/UDP (голос) и 30033/TCP (файлообмен), у Mumble — 64738 сразу по TCP и UDP. Если игровой сервер уже занимает эти номера (маловероятно, но бывает при нескольких инстансах на одной машине) — конфликт решается сменой порта в конфиге голосового сервера. Подробнее про то, как вообще открывать порты и не наделать дыр в файрволе — в статье про настройку портов и файрвола.
• Трафик суммируется. Если у тарифа ограничен канал, исходящий трафик игрового сервера (синхронизация мира с десятками клиентов) и голосового складываются в один общий лимит. В моменте пиковой нагрузки на игре (вайп, ивент, массовый заход) голос может просесть по задержке, если канал упирается в потолок.
• Рестарт игрового сервера не должен трогать голос. Если оба процесса запускаются одним скриптом или в одном контейнере без разделения — рестарт игры на обновление или вайп обрушит и войс, что раздражает комьюнити сильнее, чем сам рестарт игры. Держите голосовой сервер как отдельный systemd-юнит (или отдельный контейнер/инстанс на панели), даже если он физически живёт на одной машине с игрой.

Для небольших команд — до 10-20 человек — совместное размещение вообще не создаёт проблем и экономит деньги на втором тарифе. Для крупного паблик-сообщества разумнее развести голос и игру по разным инстансам, чтобы нагрузка одного не била по стабильности другого.

Какой тариф MAATRIX брать под голосовой сервер

Если голосовой сервер — единственное, что вам нужно (без игрового сервера на той же машине), почти всегда достаточно младшего тарифа. Даже сервер на 200+ слотов с активным войсом укладывается в 1-2 ГБ RAM и одно ядро — это далеко не тот объём, ради которого нужны средние или тяжёлые тарифы, рассчитанные на survival-игры с процедурной генерацией мира.

Практическая раскладка:

• Личный или клановый войс до 30-50 человек — минимального тарифа с запасом по RAM в пределах гигабайта хватит с большим запасом, и TeamSpeak, и Mumble будут чувствовать себя свободно.
• Комьюнити-сервер на 100-200+ слотов с активными публичными каналами — стоит смотреть не столько на RAM/CPU (они всё ещё скромные), сколько на характеристики канала у тарифа, из-за модели «один говорящий — рассылка всем слушателям», разобранной выше.
• Голос + игровой сервер на одном тарифе — берите тариф по требованиям игры (она всегда будет доминирующим потребителем RAM и CPU), а голосовой сервер добавляется практически бесплатно по ресурсам поверх.

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

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