До основного вмісту

Виділений сервер під відео та стримінг: залізо й канал

Виділені сервери · 24.09.2026
Ілюстрація до статті «Виділений сервер під відео та стримінг: залізо й канал»

Виділений сервер під відео та стримінг

Задачі тут дві, і впираються вони в різне залізо. Віддача готового відео обмежена каналом і диском: процесор майже не працює. Транскодування обмежене процесором: один потік 1080p у x264 на пресеті veryfast з'їдає кілька ядер. Рахуйте їх окремо і при зростанні розносьте на різні машини.

  • Канал рахують за формулою «бітрейт × одночасні глядачі» плюс 20% запасу на піки.
  • Транскодування програмне: E5-2680v4 з 28 потоками тягне кілька потоків 1080p одночасно, точне число дає лише тест.
  • 30 ТБ трафіку на Dedicated Start US — це приблизно 11 000 годин перегляду за бітрейту 6 Мбіт/с.
  • Сегменти HLS пишуться і читаються дрібними файлами: NVMe прибирає затримки, яких не видно на тесті лінійного читання.
  • Архів тримають окремо від робочих дисків: додатковий жорсткий диск 1 ТБ — $15/міс, вивантаження у сховище — $10/міс.

Скільки каналу потрібно під глядачів

Якість і бітрейт100 Мбіт/с (Start DE)500 Мбіт/с (Start FR)1 Гбіт/с (Pro і вище)
720p, 3 Мбіт/сблизько 25 глядачівблизько 130близько 260
1080p, 6 Мбіт/сблизько 13близько 65близько 130
4K, 20 Мбіт/сблизько 4близько 20близько 40

Цифри вже враховують 20% запасу: без нього перший же сплеск глядачів перетворюється на буферизацію в усіх одразу. Канал unmetered знімає питання обсягу, але ширина порту лишається жорсткою стелею — розбір у статті про канал сервера та ліміти трафіку. Гігабітний unmetered є на тарифах Pro та Enterprise, зокрема на майданчику в США: конфігурації зібрані на сторінці виділених серверів у США.

Транскодування: виміряйте, а не вгадуйте

Кількість потоків, яку витягне процесор, залежить від пресета, роздільності та вмісту кадру. Єдиний чесний спосіб — прогнати кодування в нікуди і подивитися коефіцієнт швидкості.

# Debian/Ubuntu
apt-get install -y ffmpeg
# RHEL/AlmaLinux/Rocky (репозиторій RPM Fusion)
dnf install -y ffmpeg

# кодуємо в /dev/null: потрібен показник speed=
ffmpeg -i source.mp4 -c:v libx264 -preset veryfast -b:v 6M \
       -c:a aac -b:a 128k -f null /dev/null 2>&1 | tail -3

Значення speed= більше за 1x означає, що потік кодується швидше за реальний час. Запас потрібен дворазовий: за speed=2x один процесор тягне приблизно два такі потоки, далі починаються пропуски кадрів. Як рахувати це при виборі тарифу — у статті про вибір процесора для сервера.

Нарізка HLS і віддача

Для мовлення на браузери стандарт де-факто — HLS: потік ріжеться на сегменти по 2–6 секунд, плейлист оновлюється, віддає все звичайний nginx.

# три якості в одному проході, сегменти по 4 секунди
ffmpeg -re -i rtmp://127.0.0.1/live/stream \
  -filter_complex "[0:v]split=3[v1][v2][v3];[v2]scale=-2:720[v2o];[v3]scale=-2:480[v3o]" \
  -map "[v1]" -c:v:0 libx264 -b:v:0 6M \
  -map "[v2o]" -c:v:1 libx264 -b:v:1 3M \
  -map "[v3o]" -c:v:2 libx264 -b:v:2 1200k \
  -preset veryfast -g 96 -sc_threshold 0 \
  -f hls -hls_time 4 -hls_list_size 6 -hls_flags delete_segments \
  -master_pl_name master.m3u8 /var/www/hls/v%v/index.m3u8 \
  > /var/log/ffmpeg-hls.log 2>&1 &

# перевіряємо, що сегменти справді з'являються і старі видаляються
watch -n 2 'ls -1 /var/www/hls/v0 | wc -l'

Каталог сегментів зручно тримати на tmpfs: живий потік усе одно перезаписується, а диск звільняється від тисяч дрібних записів. Для записів на зберігання різниця між типами накопичувачів розібрана у статті про NVMe, SATA SSD і жорсткі диски в сервері.

Зберігання архіву

Робочі диски й архів тримають окремо. Тарифи Pro дають 2×1 TB NVMe у RAID1, Enterprise US — 4×1 TB NVMe у RAID10; під архів додають жорсткий диск 1 ТБ за $15/міс або вивантажують записи в зовнішнє сховище за $10/міс. Що обрати за грошима і швидкістю віддачі, допомагає вирішити порівняння у статті про хмарні сховища S3.

Локація вирішує не менше за залізо: що далі глядач, то довше стартує плейлист і то частіше спрацьовує буферизація на піках. Методика вимірів описана у статті про вибір локації сервера.

Ліміт 30 ТБ на Dedicated Start US виглядає великим рівно до першого вдалого ефіру: за 6 Мбіт/с його вибирають приблизно 11 000 годин перегляду, тобто сотня глядачів за місяць регулярних трансляцій. Рахуйте обсяг заздалегідь і беріть unmetered, якщо аудиторія росте. Друга пастка — запускати транскодування на тому самому сервері, що й віддачу, без обмеження ресурсів: ffmpeg займе всі ядра, nginx почне віддавати сегменти із затримкою, і глядачі побачать буферизацію там, де канал вільний. Обмежуйте кодувальник через systemctl set-property ffmpeg.service CPUQuota=60% і перевіряйте результат не за «виглядає нормально», а за логами плеєра: зростання кількості зупинок за стабільного бітрейту означає, що вперлися в процесор.

Коротко

  • Віддачу обмежує канал, транскодування — процесор; рахуйте їх окремо.
  • Ширину каналу беруть як бітрейт × глядачів плюс 20%; гігабітний unmetered тримає близько 130 глядачів у 1080p.
  • Кількість потоків транскодування міряють через ffmpeg з -f null і показник speed, запас дворазовий.
  • Сегменти HLS зручніше тримати на tmpfs, архів — на окремому жорсткому диску за $15/міс або в зовнішньому сховищі за $10/міс.
  • 30 ТБ на Start US — приблизно 11 000 годин перегляду в 1080p; за зростання аудиторії потрібен unmetered.
← Назад до бази знань Поставити питання підтримці