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

MAATRIX

Icecast — один из немногих сервисов, который спокойно работает на серверах с минимальным набором ресурсов и почти не меняется десятилетиями: протокол стабилен, ядро кода отточено ещё с начала 2000-х, никаких прожорливых зависимостей. Из-за этого вопрос «сколько памяти закладывать» звучит немного иначе, чем для базы данных или веб-приложения — Icecast сам по себе почти ничего не ест, а всё потребление определяется тем, что вы к нему подключаете: сколько слушателей, сколько источников (mount points) и держите ли вы буферы истории. Разберём по цифрам, чтобы не переплачивать за сервер, но и не упереться в лимиты в разгар эфира.

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

Сам процесс icecast2 в режиме простоя, без слушателей и без активных источников — это 10-20 МБ RAM. Это буквально бинарник, конфиг и минимальный набор структур для обработки TCP-соединений. Даже на самом дешёвом VPS с 512 МБ памяти Icecast стартует и работает без проблем.

Дальше память растёт по трём направлениям:

• Каждое подключение слушателя держит небольшой буфер — обычно это десятки-сотни килобайт на клиента, в зависимости от настроенного queue-size и burst-size в конфиге. При дефолтных значениях (queue-size 524288 байт = 512 КБ на слиент) сто слушателей — это до 50 МБ буферов в пике, но по факту обычно меньше, потому что не все буферы заполнены целиком одновременно.
• Каждый source (mount point) — то есть каждый отдельный аудиопоток, который вы транслируете, — держит свой набор буферов на приём от энкодера (Liquidsoap, BUTT, ffmpeg) и раздачу слушателям. Один активный mount с несколькими битрейтами (например, 128 kbps и 320 kbps как разные точки) — это фактически два независимых потока с раздельным потреблением.
• Fallback-файлы и intro-треки, если вы их настроили в конфиге (<fallback-mount> или <intro>), Icecast может кэшировать в память при первом обращении — обычно это несколько мегабайт на трек, некритично для современных серверов, но стоит учитывать, если таких файлов десятки.

Итого простой Icecast с одним активным источником и без слушателей — это условно 20-40 МБ. Всё остальное добавляют именно слушатели и количество параллельных потоков.

Сколько добавляют слушатели — реальная арифметика

Здесь важно понимать: Icecast не транскодирует поток для каждого слушателя (в отличие от видеостриминга с адаптивным битрейтом) — он просто ретранслирует уже закодированный аудиопоток от источника всем подключённым клиентам. Это принципиально дешёвая по CPU и памяти операция, и именно поэтому Icecast десятилетиями остаётся стандартом для интернет-радио: масштабирование по числу слушателей почти линейное и без резких скачков.

Грубый ориентир по памяти на слушателей (без учёта самого процесса и источников):

Цифры ориентировочные — конкретное потребление зависит от queue-size/burst-size в конфиге, битрейта потока (320 kbps поток держит буфер большего объёма, чем 96 kbps) и от того, насколько быстро слушатели читают данные (медленные мобильные соединения задерживают буфер дольше). На вашем сервере может отличаться в разы — считайте таблицу отправной точкой для планирования, а не гарантированным числом.

Отдельно стоит следить не только за памятью, но и за сетевым каналом: 1000 слушателей на потоке 128 kbps — это уже около 128 Мбит/с исходящего трафика, и на многих тарифах VPS именно канал, а не RAM, окажется первым узким местом.

Конфигурация icecast.xml, которая влияет на память

Три параметра в icecast.xml напрямую определяют, сколько памяти съедает каждое соединение:

<limits>
    <clients>1000</clients>
    <sources>10</sources>
    <queue-size>524288</queue-size>
    <client-timeout>30</client-timeout>
    <header-timeout>15</header-timeout>
    <source-timeout>10</source-timeout>
    <burst-size>65536</burst-size>
</limits>

• clients — жёсткий потолок одновременных слушателей. Это первая защита от того, что сервер «удивит» вас нагрузкой сверх плана: если сервер рассчитан на 500 слушателей по памяти и каналу, лучше явно ограничить clients этим числом, чем упереться в OOM в прямом эфире.
• sources — потолок одновременных источников (mount points). Для личного радио хватает 2-5, для мультиканальной платформы с десятками станций число растёт вместе с базовым потреблением памяти (каждый source — это плюс несколько мегабайт постоянно, даже без слушателей).
• queue-size — размер буфера на одного клиента в байтах. Уменьшение с дефолтных 512 КБ до, скажем, 128 КБ снижает пиковое потребление на большом числе слушателей, но увеличивает риск обрывов на нестабильных соединениях — компромисс между памятью и устойчивостью для мобильных слушателей.
• burst-size — сколько данных отдаётся клиенту сразу при подключении, чтобы плеер быстрее начал воспроизведение. Больше burst-size — комфортнее старт для слушателя, но выше кратковременный расход памяти при массовом подключении (например, если ссылку на эфир кинули в большой чат и все зашли одновременно).

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

Сколько RAM закладывать под разные сценарии

Собираем всё вместе — ориентировочные конфигурации под типичные случаи использования:

Разница между «RAM для Icecast» и «рекомендуемая RAM сервера» не случайна: сам Icecast — это только часть картины. На том же сервере обычно крутится Liquidsoap или другой энкодер для формирования потока (сам по себе может брать 100-300 МБ в зависимости от сложности плейлиста и обработки аудио), плюс ОС, systemd-сервисы, возможно nginx как reverse proxy перед Icecast для SSL. Закладывать «впритык» под голый Icecast — плохая идея: сколько оперативной памяти закладывать с запасом — тот случай, где запас особенно оправдан, потому что резкий наплыв слушателей (например, ссылку кто-то репостнул) — это не постепенный рост, а скачок за секунды.

Liquidsoap рядом с Icecast — не забывайте про энкодер

Отдельная и частая ошибка при планировании сервера — считать только Icecast, забывая, что источник потока почти всегда отдельный процесс. Если вы используете Liquidsoap для формирования эфира (плейлисты, джинглы, кроссфейд, live-входы), это дополнительный и не всегда маленький потребитель:

• Простой скрипт с одним плейлистом и перекодированием в MP3/AAC — 80-150 МБ.
• Плейлист со сложной логикой (несколько источников, live-переключение, обработка аудио вроде нормализации громкости через normalize или compress) — 150-300 МБ.
• Несколько параллельных станций через один Liquidsoap-процесс (мультиканальное вещание) — потребление растёт почти линейно с числом каналов.

Если энкодер и Icecast стоят на одном сервере (обычная практика для небольших проектов — не нужно гонять аудиопоток по сети между двумя машинами), суммируйте оба потребления при выборе плана. Для связки «Liquidsoap с 2-3 источниками + Icecast на 200-500 слушателей» комфортный минимум — 2 ГБ RAM, с запасом на скачки и системные процессы.

Практические советы по экономии и настройке

Несколько вещей, которые реально влияют на потребление и стабильность, без лишней теории:

• Ограничивайте clients явно. Дефолтное значение в примерах конфигов (иногда 100 или даже без явного лимита) не защищает вас от неожиданного всплеска — лучше сервис вежливо откажет в подключении сверх лимита, чем сервер уйдёт в своп и уронит вообще всё.
• Не держите лишние mount points «про запас». Каждый настроенный, но неактивный source не потребляет много, но зря усложняет конфиг и мониторинг — удаляйте то, чем реально не пользуетесь.
• Настройте systemd unit с ограничением памяти, если хотите жёстко застраховаться от переполнения на общем сервере:

[Service]
MemoryMax=512M
MemoryHigh=400M

Это не даст Icecast (или связке с Liquidsoap, если вынести в отдельный unit) съесть память других сервисов на том же VPS — процесс скорее получит OOM-kill при выходе за лимит, чем утащит весь сервер в своп.

• Проверьте firewall заранее, особенно если сервис публичный и слушатели заходят на нестандартный порт (обычно 8000 для Icecast) — настройка ufw на Ubuntu 24.04 пригодится, чтобы открыть только нужный порт и не оставлять сервер открытым по всем направлениям.
• Swap как страховка, а не как план. Icecast редко упирается в память сам по себе, но если на том же сервере крутится ещё десяток сервисов, небольшой swap спасёт от OOM-kill в моменты пиковой нагрузки — как его настроить, описано в статье про swap-файл: когда нужен и как настроить.

Какой сервер брать под Icecast

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

• Личный проект, тест, до 50 слушателей — 1 vCPU, 512 МБ - 1 ГБ RAM достаточно с большим запасом.
• Небольшая станция, до 500 слушателей, 1-3 источника — 1-2 vCPU, 2 ГБ RAM — комфортный вариант с учётом Liquidsoap рядом.
• Публичный проект на 1000+ слушателей — 2 vCPU, 4 ГБ RAM плюс внимание к исходящему сетевому каналу (это может оказаться более узким местом, чем память).

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

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