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

MAATRIX

Owncast — это свой собственный аналог Twitch: вы поднимаете его на VPS, стримите туда через OBS по RTMP, а зрители смотрят через браузер, без Google, без блокировок и без чужих правил модерации. Вопрос «сколько нужно памяти» здесь не такой прямой, как для базы данных или чат-бота — расход RAM у Owncast зависит не столько от того, сколько людей смотрит, сколько от того, включили ли вы транскодирование потока в несколько качеств. Разберём по цифрам, чтобы не гадать и не переплачивать за тариф, который вам не нужен.

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

Owncast написан на Go и распространяется одним бинарником — сам по себе процесс лёгкий, встроенная база SQLite тоже почти ничего не весит. Но вокруг этого ядра крутятся три статьи расхода памяти, и именно они определяют реальный аппетит сервиса:

• Приём и транскодирование потока. Owncast принимает RTMP-поток от OBS и, если вы включили дополнительные качества (variants) в панели администратора, запускает ffmpeg-процессы, которые перекодируют исходный поток в более низкие разрешения и битрейты. Каждый такой процесс — это отдельные буферы кадров в памяти, и чем выше разрешение и частота кадров исходника, тем они тяжелее.
• Упаковка в HLS. Результат (исходный поток и все транскодированные варианты) режется на сегменты .ts и .m3u8 плейлисты для отдачи по протоколу HLS. Сегменты пишутся на диск, но часть буферов держится в памяти до записи — на слабом диске это создаёт дополнительное давление на RAM через кэш страниц ОС.
• Раздача зрителям и чат. Сам HTTP-сервер Owncast раздаёт HLS-сегменты и держит WebSocket-соединения для чата. Это самая лёгкая часть — на каждого зрителя уходят единицы мегабайт, а не десятки, потому что видео зрители получают статическими файлами, а не отдельным потоком с сервера.

Из этого следует главный вывод: транскодирование, а не количество зрителей, определяет, сколько RAM вам заложить. Сервер на 100 зрителей без транскодирования съедает меньше памяти, чем сервер на 10 зрителей с тремя дополнительными качествами.

Passthrough без транскодирования: минимальный сценарий

Если вы отдаёте зрителям тот же поток, что пришёл от OBS, без пересжатия (в панели Owncast это режим, когда включён только исходный variant), нагрузка на CPU и RAM минимальна:

• сам процесс Owncast в простое — обычно укладывается в 150-250 МБ;
• под нагрузкой (активный стрим, десятки зрителей, чат) добавляется ещё 100-300 МБ на буферы HLS и сессии;
• итого разумный минимум — 1 ГБ RAM, но с очень небольшим запасом на скачки (обновление ОС, случайный всплеск зрителей, фоновые задачи вроде бэкапа).

На практике для домашнего или клубного стрима без транскодирования 2 ГБ RAM — комфортный минимум: остаётся запас под ОС (Ubuntu/Debian в простое сама по себе держит 150-300 МБ), nginx как reverse proxy для SSL и разовые операции вроде записи VOD на диск.

Важная оговорка: passthrough означает, что зрители со слабым интернетом или маленьким экраном получают тот же битрейт, что и все остальные — качество подстроить под них нельзя. Это осознанный компромисс ради экономии ресурсов сервера.

Транскодирование: где RAM начинает решать

Как только вы включаете дополнительные качества (например, 1080p исходник + варианты 720p и 480p), Owncast поднимает отдельный процесс ffmpeg на каждый variant. Здесь оценки уже не такие однозначные — точный расход зависит от кодека, пресета скорости кодирования (veryfast, fast, medium — чем медленнее пресет, тем выше качество на бит, но и нагрузка на CPU/RAM больше) и разрешения источника. Ориентировочно закладывайте так:

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

Отдельно стоит сказать про CPU: программное транскодирование (то, что делает ffmpeg по умолчанию) — это в первую очередь нагрузка на процессор, и на слабом VPS с 1-2 виртуальными ядрами транскодирование в несколько качеств будет упираться в CPU раньше, чем в память. Если планируете больше двух дополнительных качеств, берите тариф с 4 ядрами и выше, не только с запасом по RAM.

Зрители и чат: почему это не главный фактор

Многие ожидают, что расход памяти будет линейно расти с числом зрителей, как в схемах с прямой раздачей RTMP или WebRTC. У Owncast это не так, потому что видео зрители получают статическими HLS-файлами через обычный HTTP — сервер просто отдаёт файлы с диска, это дёшево по памяти и хорошо кэшируется ОС.

Реальный расход на зрителей складывается из:

• WebSocket-соединений чата — каждое живое соединение держит небольшой буфер, на практике счёт идёт на десятки-сотни килобайт на зрителя, а не мегабайты;
• HTTP-соединений на раздачу плейлистов — короткоживущие, закрываются между запросами сегментов;
• истории чата в памяти — Owncast хранит недавние сообщения для новых подключений, это тоже некритичная по объёму структура.

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

Диск и сеть — на что ещё смотреть кроме памяти

Память — не единственный ресурс, который «сыпется» при недооценке под Owncast:

• Диск. HLS-сегменты пишутся постоянно, пока идёт стрим — на медленном HDD или сетевом хранилище с задержками это создаёт очередь операций записи, которая рикошетом бьёт по памяти (растёт неотданный page cache). Берите SSD или NVMe — разница между SSD и NVMe в VPS здесь ощущается напрямую в стабильности стрима, а не только в цифрах бенчмарков.
• Место под VOD. Если включена запись прошедших трансляций (video-on-demand), считайте отдельно: час стрима в 1080p на разумном битрейте — это несколько гигабайт, и они накапливаются быстро. Это не RAM, а именно дисковое пространство, но нехватка свободного места на диске у Linux тоже может проявляться как нехватка памяти через забитый page cache.
• Исходящий трафик. Каждый зритель скачивает свой поток целиком — при десятках одновременных зрителей на 1080p счёт легко идёт на сотни гигабайт трафика в месяц. Проверьте лимиты тарифа заранее, это отдельная статья расходов от RAM.
• Swap как страховка, а не основа. На тарифах с транскодингом полезно настроить своп нужного размера — не как замену оперативной памяти (диск в разы медленнее RAM, и стрим начнёт лагать при активном использовании подкачки), а как амортизатор от разового всплеска, который иначе привёл бы к OOM-killer и обрыву трансляции.

Таблица: сколько RAM брать под конкретный сценарий

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

Для старта с одним каналом без амбиций на мультикачество вполне хватит 2 ГБ. Если сразу знаете, что будете давать зрителям выбор качества — закладывайте 4 ГБ и выше, и держите под рукой 2-4 ядра CPU, иначе транскодинг упрётся в процессор раньше, чем в память.

Как проверить реальный расход на своём сервере

Таблицы выше — это стартовая точка, а не гарантия. Проверить фактический расход просто:

# общая память и swap в реальном времени
free -h

# что именно ест RAM: процесс owncast и ffmpeg-транскодеры
ps aux --sort=-%mem | grep -E 'owncast|ffmpeg' | grep -v grep

# нагрузка по ядрам CPU во время активного стрима
top -o %CPU

Запустите стрим с планируемой конфигурацией качеств на несколько минут, посмотрите на RES (resident memory) у процессов owncast и ffmpeg, и добавьте 30-40% запаса сверху под пиковые моменты (начало стрима, момент, когда все зрители подключились почти одновременно). Если видите, что free -h показывает активное использование swap уже в первые минуты — это сигнал брать тариф на ступень выше, а не оптимизировать дальше.

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