Зависания видео в эфире

[D3Qzzz]

Добрый день!

4 июля на трансляции столкнулись с многократным зависанием видеоизображения.
За два часа до старта эфира запустили тестовый поток. В этот период не было зафиксировано никаких проблем.

После старта эфира, примерно на пятидесятой минуте, в плеере зависло видеоизображение. В принудительном режиме пришлось перезагрузить через админку плеер. То же самое повторялось со средней периодичностью раз в 20 минут (а где-то и 2 зависания подряд было) вплоть до окончания эфира. В сумме за 4-х часовой эфир было зафиксировано около 9 подобных эпизодов.

При этом, что важно, в окне локального просмотра все было ок, проблема возникала именно в плеере.
При тестах без подключений зрителей, подобные сбои не фиксировались.

Помогите решить проблему.

 

[Max]

Добрый день.
К сожалению, ваш запрос не содержит ни одной технической детали, которая бы помогла понять, в чем заключается проблема, и как ее решить. Примерный список информации приведен здесь: Как обратиться за поддержкой.
Поэтому просим собрать отчет, как описано здесь: Сбор отладочных логов при помощи скрипта report.sh, и выслать нам, используя эту форму. Если архив отчета занимает более 30 Мб, разместите его на публичном хранилище (Google Drive, OneDrive, Yandex Disk) и пришлите ссылку в поле Comment этой формы.
Просим также предоставить SSH доступы к серверу в этой форме. Подробнее об организации доступа к серверу смотрите здесь:
Организация доступа инженеров технической поддержки к Вашему серверу.
Наши инженеры проверят отчет и сервер и дадут дальнейшие рекомендации.

 

[Max]

Проверили ваш отчет.
К сожалению, в нем доступны логи сервера только за последние три часа, и в них нет информации о публикациях потоков. По логу сборщика мусора (GC) видно, что Java heap память (6 Gb) не заполнялась полностью, длительных пауз в работе Java машины не было, что косвенно указывает на отсутствие явных проблем в работе сервера.
Однако есть следующие вопросы к конфигурации:
1. В настройках одновременно используются два различных механизма оптимизации раздачи WebRTC подписчикам

Такая настройка не рекомендуется к эксплуатации. Рекомендуем убрать параметры av_paced_sender и rtp_paced_sender... из файла настроек, вернув их к значениям по умолчанию
2. Используется устаревшая версия WCS. Рекомендуем обновить сервер до последней сборки 5.2.2016.
3. Используется сброщик мусора G1, который может давать значительные задержки в работе Java машины под нагрузкой. Рекомендуем обновить JDK, например, до JDK 17 и включить сборщик мусора ZGC: Настройка Z Garbage Collector (ZGC)

Проблемы, которые описаны в первом сообщении, могут быть связаны и с тем, что количество подписчиков, подключенных к серверу и играющих поток, превысило пропускную способность канала между подписчиками и сервером. В этом случае необходимо знать:
1. Параметры публикации потоков (разрешение, битрейт).
2. Количество зрителей в момент, когда была зафиксирована проблема.
Также требуется уточнить, с каким разрешением зрители играли потоки (указывалось разрешение при проигрывании или нет). Если указывалось, то на сервере включался транскодинг, который мог превышать возможности CPU сервера.

 

[mafet]

1. Уберём лишние параметры.
2. Обновим.
3. Обновить JDK надо на сервере? А как понять какой сборщик мусора используется.
--
1. Подаётся 1280х720 через "Media devices", битрейт от 750 до 1500 выставлен. Канал вроде как не ограничен на сервере.
2. Около 99. Транскодинг не включался. Загрузка cpu по htop была нормальная.

И что бы выявить настоящую причину проблемы, подскажите, как провести нагрузочное тестирование? Можете ли дать инструмент для создания нагрузки по webrtc. Будем поэтапно применять ваши рекомендации.

Так же что скажете по поводу данных рекомендаций от коллеги:
curl -s 'https://liquorix.net/install-liquorix.sh' | sudo bash
ребут
во вторых
net.ipv4.tcp_congestion_control=bbr
net.ipv4.tcp_window_scaling=1
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_max_orphans это непонятно почему выкручено
поставь дефолт
net.ipv4.tcp_keepalive_time = 15
net.ipv4.tcp_max_syn_backlog тоже можно дефолтным оставить
net.ipv4.tcp_orphan_retries это тоже убрать на дефолт
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 0
лучше net.ipv4.tcp_tw_reuse =0
net.core.netdev_max_backlog = 2500 я бы уменьшил

 

[Max]

3. Обновить JDK надо на сервере? А как понять какой сборщик мусора используется.

Да, обновить JDK надо на сервере, если установлен JDK ниже 12. Тип сборщика мусора виден в его логе gc-core-....log

Канал вроде как не ограничен на сервере.

Проводилось ли тестирование канала, например с iperf3?

И что бы выявить настоящую причину проблемы, подскажите, как провести нагрузочное тестирование? Можете ли дать инструмент для создания нагрузки по webrtc. Будем поэтапно применять ваши рекомендации.

Методика тестирования описана в этой статье: Какой нужен сервер для 1000 WebRTC стримов?
Техническая документация по тестированию здесь: Нагрузочное тестирование с использованием захвата потоков по WebRTC/RTMP

Так же что скажете по поводу данных рекомендаций от коллеги:

Речь идет о тюнинге TCP стека, а WebRTC использует UDP. В этом случае рекомендуется изменить только две настройки ядра

sudo sysctl -w net.core.rmem_max=26214400
sudo sysctl -w net.core.rmem_default=26214400

 

[mafet]

Мы сейчас перешли на TCP транспорт для клиентов и для вещания из-за того, что в UDP совсем плохо всё было.

Проводилось ли тестирование канала, например с iperf3?

тест проводился с помощью speedtest

# speedtest

   Speedtest by Ookla

     Server: Polycomm - Moscow (id = 21110)
        ISP: LLC VK
    Latency:     1.23 ms   (0.04 ms jitter)
   Download:  6375.02 Mbps (data used: 10.6 GB )                               
     Upload:  5251.89 Mbps (data used: 5.6 GB )                               
Packet Loss:     0.0%

 

[Max]

Мы сейчас перешли на TCP транспорт для клиентов и для вещания из-за того, что в UDP совсем плохо всё было.

Из предоставленного отчета этого не видно, т.к. там вообще нет данных о публикации и проигрывании. На стороне сервера TCP транспорт не включен.

тест проводился с помощью speedtest

Мы рекомендуем использовать iperf. В любом случае, эти тесты дают лишь очень приблизительную картину.
Есть тест, задействующий WebRTC data channels, который дает максимальную пропускную способность, близкую к реальной, но он предназначен для тестирования канала публикации: Тестирование пропускной способности канала публикации.
Также есть возможность контроля качества канала при публикации/проигрывании с отображением на сторонее клиента: Контроль качества канала при публикации и воспроизведении.

 

[mafet]

Было сделано следующее:
Обновлен JDK до 17, обновлён сам WCS. Применены все рекомендации: ZGC, AES, и некоторые другие.
Обновлена ОС до bookworm, Установлено ядро liquorix.
Всё это особо не помогало.

Однако изменение железа для виртуалки на "высокопроизводительное", как обозначено в нашем облачном провайдере радикально положительно повлияло.
Сервер сейчас держит нагрузку в 200 пользователей в 720p почти без фризов.
Что вы можете сказать по поводу вот этих нюансов использования виртуалок и что порекомендуете делать?
и подскажите пожалуйста по данным параметрам:
Fir Count: 0
Jitter Buffer Emitted Count: 7597
Nack Count: 1
Pause Count: 0
Pli Count:
остальные вроде более-менее понятны.

 

[Max]

Что вы можете сказать по поводу вот этих нюансов использования виртуалок и что порекомендуете делать?

По репорту, вы использовали 6 vCPU и 12 Gb RAM. Действительно, для большого количества потоков 720p этого недостаточно. WebRTC требует много ресурсов, с учетом шифрования. Был бы транскодинг, ресурсов потребовалось бы еще больше
Когда-то мы проводили тестирование производительности сервера в применении к облачным инстансам AWS и вынесли результаты в документацию: Тестирование производительности сервера. Эту документацию можно использовать как референс, но конфигурации быстро меняются. Поэтому наиболее правильным решением будет при миграции на новый сервер проводить нагрузочное тестирование, как рекомендовано в этом сообщении.

Fir Count: 0
Jitter Buffer Emitted Count: 7597
Nack Count: 1
Pause Count: 0
Pli Count:

Это все параметры статистики WebRTC, которые отдает нам браузер. Описания параметров можно посмотреть для исходящих соединений (публикаций) здесь, для входящих (зрителей) здесь. Наибольший интерес здесь представляет счетчик Nack Count, который показывает число неподтвержденных пакетов медиаданных. Если это число растет, налицо проблемы с каналом до сервера.

 

[mafet]

Ну вот у вас на тесте (1 CPU, 2 GB RAM, 1 GB RAM для Java heap) и тянет 120 зрителей при 720p.
У нас же 6/12 не тянет и 100 зрителей. Какая-то ерунда не здоровая.
Транскодинг мы не используем, а вот шифрование оно по умолчанию есть да? Его нельзя выключить?
По параметрам принято. Но вообще nack тоже были, но кажется это изза проблем с виртуалкой.
А что еще по параметрам посоветуете подкрутить? Мы доступ вам высылали.
В частности вот например
------------
# ZGC
-XX:+UseZGC -Xms6g -Xmx6g
при
### JVM OPTIONS ###
-Xmx6g
-Xms6g
------------
при 12 гб это нормальные параметры?
Ну и может еще что-то надо подкрутить

 

[Max]

Доступы не получили.
Продублируйте пожалуйста через эту форму.
Для более безопасной организации доступа по SSH можете импортировать наш публичный ключ.

Попробуйте также настройку если она еще не включена

streaming_distributor_video_proxy_pool_enabled=true

пункт 8

Шифрование выключить нельзя. Это невыключаемая фича WebRTC.

Однако, если некритична задержка в несколько секунд, можно попробовать играть по LL HLS.
Этот способ воспроизведения меньше ресурсов чем WebRTC. При этом LL HLS может потребовать более стабильного источника потока, например OBS Studio RTMP, либо транскодирования на сервере в облее стабильный поток для раздачи по HLS.

-Xmx6g -Xms6g

Да это рекомендуемые параметры при 12 гб реальной памяти.

Только не нужно их дублировать в одном файле. Так достаточно:

# ZGC
-XX:+UseZGC -Xms6g -Xmx6g

Кроме этого, желательно подключить сервер к Zabbix либо к Prometheus+Grafana чтобы отслеживать нагрузку по процессору и памяти во время стриминга.

 

[mafet]

отправил. ip адрес заканчивается на .185, проверьте.
завтра у нас мероприятие по Мск
но вроде сейчас все норм, можно вернуться в понедельник

 

[Max]

Доступ заработал.
Проблем в конфигурации не видно.
Во время мероприятия желательно мониторить ключевые параметры:

- Heap память Java
- CPU распределение загрузки по ядрам (например htop)
- RSS (RAM) свободная память
- Паузы сборщика мусора gc.log
- Threads count - общее количество тредов

Более подробно про метрики

10 важных метрик WebRTC стриминга и настройка мониторинга Prometheus +Grafana | Flashphoner Streaming & Calls for Web

flashphoner.com