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

MAATRIX

На вопрос «сколько RAM нужно для PeerTube» официальная документация отвечает уклончиво: формально хватает и 1 ГБ, если транскодирование выключено. Но выключенное транскодирование — это видео, которое проигрывается ровно в том разрешении, в каком его залил автор, без адаптивного битрейта и без экономии трафика на мобильном интернете. Реальный расход памяти определяют три независимых процесса — Node.js-бэкенд, транскодирование через ffmpeg и федерация ActivityPub — и складываются они не всегда очевидным образом. Ниже — разбор по компонентам, команды замера на живой системе и рабочие конфиги под ограниченную память.

Короткий ответ: сколько закладывать

Цифры для связки Node.js 20 LTS + PostgreSQL 15 + Redis + nginx на Ubuntu 24.04, PeerTube актуальной ветки (7.x, HLS-only, легаси WebTorrent-формат из проекта убран). Оценки по транскодированию — ориентировочные: конкретное потребление ffmpeg зависит от кодека, битрейта источника и числа одновременных заданий на вашем сервере, поэтому проверяйте на своём контенте.

Строчку вниз двигает не число зрителей, а число одновременных заданий транскодирования и загрузок — просмотр готового HLS-плейлиста почти не требует памяти сверх nginx, отдающего статику. Диска стабильно нужно больше, чем RAM: считайте объём видео в оригинальном качестве плюс копии под каждое разрешение, если не выносите хранилище в S3-совместимый бакет.

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

Официальная установка через peertube-cli или docker-compose поднимает четыре процесса: сам PeerTube (Node.js), PostgreSQL, Redis и nginx перед ними. Разложим на слагаемые машину на 4 ГБ с небольшим активным сообществом.

Ключевой момент: ffmpeg — внешний процесс, запускаемый через child_process, а не часть памяти Node.js. Смотреть RSS одного node и делать вывод «PeerTube ест 300 МБ» — ошибка: пока идёт транскодирование, рядом висят один или несколько процессов ffmpeg со своим потреблением. Проверить разом:

ps aux --sort=-%mem | grep -E 'node|postgres|redis|ffmpeg|nginx' | grep -v grep

И через free -m смотрите не на free, а на available — Linux активно отдаёт память под дисковый кеш для файлов видео, это нормально:

               total        used        free      shared  buff/cache   available
Mem:            3921        1720         180         90          2020        1950
Swap:           2047          12        2035

Транскодирование — главный пожиратель RAM

Транскодирование запускается при каждой загрузке видео и генерирует HLS-плейлист с несколькими разрешениями. Сколько заданий выполняется одновременно и сколько разрешений на каждое видео — задаётся в config/production.yaml:

transcoding:
  enabled: true
  allow_additional_extensions: true
  concurrency: 2
  resolutions:
    "144p": false
    "240p": true
    "360p": true
    "480p": true
    "720p": true
    "1080p": false
    "1440p": false
    "2160p": false
  hls:
    enabled: true
  web_videos:
    enabled: true

Каждая включённая строка в resolutions — отдельное задание ffmpeg на загрузку. Пять разрешений, concurrency: 2 — значит одновременно работают до двух ffmpeg-процессов, а остальные три ждут очереди в Redis. concurrency: 1 на слабом сервере не даёт параллельным загрузкам сложить свои ffmpeg друг на друга и увести машину в своп, ценой — более долгой обработкой очереди.

Кодек тоже влияет: профиль по умолчанию (libx264) даёт предсказуемое потребление, а альтернативные transcoding.profile с VP9 или AV1 считают заметно тяжелее — держат в памяти больше промежуточных буферов ради меньшего размера файла. На тесном по RAM сервере лучше остаться на профиле по умолчанию.

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

Федерация ActivityPub: что она добавляет к нагрузке

PeerTube — не изолированный видеохостинг, а часть федеративной сети через ActivityPub: инстансы подписываются друг на друга, получают уведомления о новых видео, комментариях и лайках. По памяти это не отдельный процесс, а дополнительная нагрузка на уже перечисленные компоненты через очередь заданий в Redis:

• Входящие Activity (Follow, Create, Like, Announce) от инстансов, на которые вы подписаны, разбираются и пишутся в PostgreSQL — рост базы, а не RAM Node.js.
• AP refresher периодически перепроверяет актуальность данных о видео и акторах с удалённых инстансов — регулярные фоновые HTTP-запросы и записи в базу.
• Импорт превью и аватаров с федерированных инстансов проходит через ту же очередь миниатюр, что и локальные загрузки — на каждую новую картинку короткий всплеск памяти на генерацию thumbnail.

На небольшом инстансе (десятки подписок) это заметно только в логах. На инстансе с сотнями подписок очередь в Redis и запись в PostgreSQL становятся постоянным фоновым потоком — узким местом чаще оказывается не RAM, а число соединений с базой (max_connections). Отключить федерацию совсем можно флагом federation.enabled: false — вариант для приватного инстанса без цели быть частью общей сети.

Прямые трансляции: отдельный расчёт

Live-трансляции — единственный сценарий в PeerTube, где ffmpeg работает не разово, а непрерывно на протяжении всего эфира. Конфиг:

live:
  enabled: true
  max_instance_lives: 4
  max_user_lives: 1
  transcoding:
    enabled: true
    resolutions:
      "480p": true
      "720p": true
    always_transcode_original_resolution: true
    concurrency: 2

Разница с обычной загрузкой: пока идёт эфир, под каждый активный поток висит ffmpeg-процесс, обрабатывающий видео в реальном времени, и держит память до тех пор, пока автор не остановит трансляцию — в отличие от VOD-транскодирования, которое заканчивается за минуты и освобождает ресурсы.

Самый дешёвый по ресурсам режим — трансмуксинг без перекодирования (live.transcoding.enabled: false): PeerTube просто переупаковывает входящий RTMP-поток в HLS без изменения кодека, памяти и CPU уходит на порядок меньше, но зрители получают ровно то разрешение и битрейт, что шлёт кодирующая программа автора. На сервере с ограниченной RAM разумный компромисс — max_instance_lives: 1–2 и не больше двух разрешений транскодирования, иначе один активный эфир на пике займёт больше памяти, чем весь остальной инстанс вместе взятый.

Конфиг и оптимизация под ограниченную память

Расклад для сервера на 2 ГБ, небольшое сообщество, 3–5 активных авторов. Логика: 2048 МБ минус 300 (PostgreSQL) минус 40 (Redis) минус 250 (система и nginx) — на PeerTube и одно задание ffmpeg остаётся около 1400 МБ, этого хватает при concurrency: 1.

# config/production.yaml — фрагмент
transcoding:
  enabled: true
  concurrency: 1
  resolutions:
    "240p": true
    "360p": true
    "480p": true
    "720p": false
    "1080p": false
live:
  enabled: false

PostgreSQL — консервативно под общий объём памяти:

# /etc/postgresql/15/main/postgresql.conf
shared_buffers = 256MB
effective_cache_size = 768MB
work_mem = 8MB
maintenance_work_mem = 64MB
max_connections = 50

Подробный разбор параметров — в статье про тюнинг PostgreSQL на VPS; там же логика расчёта shared_buffers под конкретный объём RAM, применимая и к базе PeerTube. Redis для очереди задач не нуждается в большом maxmemory — задачи в нём временные, а не постоянное хранилище:

maxmemory 64mb
maxmemory-policy noeviction

Три вещи, которые дают больше эффекта, чем апгрейд тарифа:

• Вынести видео в S3-совместимое хранилище. object_storage.enabled: true снимает с локального диска копии в каждом разрешении и немного разгружает дисковый кеш при отдаче через nginx X-Accel-Redirect. Бакет можно поднять на том же сервере через установку MinIO на VPS — сколько RAM заложить под сам MinIO, разобрано в статье сколько RAM нужно для MinIO.
• concurrency: 1 на маленьком сервере — не жадность, а страховка. Два параллельных ffmpeg на 720p легко съедают гигабайт-полтора одновременно; на 2 ГБ это гарантированный своп при двух загрузках подряд.
• Своп на 2 ГБ обязателен, если памяти впритык: fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile, строка в /etc/fstab. Это подушка на пик, а не постоянная память — если своп занят не только на пиках, пора повышать тариф. Общий чек-лист — в статье что делать при нехватке RAM.

Какой сервер взять в MAATRIX

Честный минимум: 2 vCPU, 2 ГБ RAM, 60 ГБ NVMe. Формально PeerTube заводится и на 1 ГБ без транскодирования, но это не рабочий сценарий — видео без адаптивного качества плохо смотрится на мобильном интернете. На двух ядрах и двух гигабайтах живёт небольшое сообщество с concurrency: 1 и разрешениями до 480–720p.

Комфортный вариант: 4 vCPU, 4–8 ГБ RAM, 160–300 ГБ NVMe. Подходит большинству реальных инстансов: несколько параллельных транскодирований, разрешения до 1080p, активная федерация с десятками инстансов. Второе и третье ядро здесь важнее лишнего гигабайта — ffmpeg упирается в CPU раньше, чем в память.

Нужны прямые трансляции с транскодированием: от 6 vCPU, 8–16 ГБ RAM. Live держит ffmpeg запущенным на всё время эфира — считайте ресурсы на пиковое число одновременных трансляций, а не на пиковое число зрителей.

Локация — Лондон или США, если аудитория за пределами России: HLS-сегменты чувствительны к задержке, а федерация с крупными (в основном европейскими) инстансами идёт быстрее из соседней с ними точки. Для аудитории внутри РФ — российская локация, в том числе из-за вопросов 152-ФЗ, если инстанс хранит персональные данные пользователей.

Диск наращивайте отдельно от RAM: NVMe нужен под оригиналы видео плюс копии в каждом включённом разрешении, если не вынесли хранилище в S3. Оплата серверов MAATRIX — картами российских банков, по СБП, криптовалютой или токеном MAAT; иностранная карта не понадобится и для лондонской, и для американской площадки.

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