VideoProcessor - VideoProcessor Encoding fails to keep up with decoding and decoder coded video frames queue

A

Artem_DevOps

New Member
Добрый день, нужна помочь с ошибками при работе transcoder.

Наша архитектура

Origin сервер, transcoder сервер, и несколько серверов edge.

После старта сервера transcoder работает нормально, по истечении 4-5 часов в логах начинаю появляться предупреждение:
17:48:12,646 WARN VideoProcessor - VideoProcessor-326-a801ea80-8336-43b2-a5c9-170a5e9e41ab Encoding fails to keep up with decoding and decoder coded video frames queue is about to overflow, keep decoding instead of dropping frames, queueSize 297 maxQueueSize 300 encoderQueueSizeAllowed 3

которых со временем становиться все больше, сервер начинает расти по RAM, далее рестарт и ситуация повторяется.
 
Max

Max

Administrator
Staff member
Добрый день.
Обычно так происходит, когда процессор не справляется с нагрузкой и не успевает кодировать стримы.
Не успевать может как весь CPU, если стримов на сервере много, так и процессорное ядро, если стрим кодируется в большом разрешении, например Full HD 1920 x 1080.

Поэтому нужно выяснить cколько стримов на сервере, сколько энкодеров, какие очереди транскодеров, и т. д.
Это проще всего сделать, запросив статистику несколько раз, например 5 раз через каждые 5 секунд.

Какой процессор у сервера? Сколько процессоров?

Кроме этого, желательно подключить систему мониторинга с отслеживанием основных метрик.

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

flashphoner.com flashphoner.com

Зная статистику, можно понять - это не успевает ядро либо не успевают все CPU из-за большого кол-ва стримов.

1) Если не успевают все CPU, то надо либо подавать меньше стримов, либо увеличивать ресурсы CPU либо вводить еще один транскодер и перераспределять стримы на него.

2) Если не успевает ядро CPU, отключать на сервере Hyperthreading в настройках BIOS и смотреть модель процессора.
 
A

Artem_DevOps

New Member
Добрый день, параметры нашего сервера транскодера:

CPU: 4x Intel Xeon Platinum 8160

Memory: 192GB DDR4 RAM

Uplink: 2Gbit/s


Метрики собираем, пример отправил на почту.



Параметр transcoding_video_decoding_max_queue_size периодически скачет с значения 3-5 до 300



Что касается нагрузки на CPU в целом по метрикам нагрузка за несколько месяцев не превышала 75% в основном 50%



Если смотреть htop нагрузку на каждый процессор то есть несколько процессов загруженных на 100, но их не много 2-4 из 192, да и то не всегда.
 

Attachments

A

Artem_DevOps

New Member
Да ещё по количеству стримов в среднем 50, когда 70 тогда очередь transcoding_video_decoding_max_queue_size ниже 300 не опускается
 
Max

Max

Administrator
Staff member
Artem_DevOps said:
Если смотреть htop нагрузку на каждый процессор то есть несколько процессов загруженных на 100, но их не много 2-4 из 192, да и то не всегда.
Click to expand...
Это основной симптом возникающей проблемы. Распределение нагрузки по гипертрединговым ядрам для этих процессоров работает не совсем корректно, большинство кодирований складываются на несколько ядер. В результате ядра перегружаются, и не успевают кодировать картинки, лежащие в очередях, что и показывает статистика.
Первое, что необходимо сделать - отключить гипертрединг в BIOS, чтобы на сервере были доступны только физические ядра.
Artem_DevOps said:
CPU: 4x Intel Xeon Platinum 8160
Click to expand...
У этого процессора 24 физических ядра. Если у Вас в сервере 4 таких процессора, общее число физических ядер 96.
Далее, по метрикам, у вас кодирование в 720p в большинстве случаев (109 стримов кодируются):
Code: 
native_resources{param="native_resources.video_encoders"} 109
Поэтому можно не менять настройку video_encoder_second_thread_threshold, многопоточное кодирование работает и так. Можно увеличить количество процессорных потоков для кодирования одного стрима, например
Code: 
video_encoder_max_threads=6
Так мы добиваемся более равномерного распределения нагрузки по процессорным ядрам.
Кроме того, тесты, проведенные нами на серверах с такими процессорами, показывают, что максимальное число кодируемых стримов не должно превышать число физических ядер, с запасом 20%. Таким образом, максимальное количество кодируемых стримов, допустимое для Вашего транскодера, составляет 76:
Code: 
cdn_transcoder_video_encoders_threshold=76
При достижении этого числа кодирований, Transcoder не будет пускать новых подписчиков с Edge серверов с новыми профилями кодирования. Если требуется больше кодирований, необходимо вводить в CDN еще один Transcoder сервер.
 
A

Artem_DevOps

New Member
Добрый вечер!

Рекомендации выполнили, пока ошибок стало меньше мониторим, но проблема с потреблением RAM осталась, если раньше сервер нужно было раз в 30 часов перезагружать либо дождаться OOM killer теперь раз в 50 часов рестарт, библиотеки jemalloc для распределения памяти у нас стоит, подскажите как ещё можно повлиять на проблему.

И второй вопрос если вводить ещё один Transcoder сервер можете порекомендовать наиболее оптимальный процессор для Transcoder сервер
 
Max

Max

Administrator
Staff member
Artem_DevOps said:
Рекомендации выполнили, пока ошибок стало меньше мониторим, но проблема с потреблением RAM осталась, если раньше сервер нужно было раз в 30 часов перезагружать либо дождаться OOM killer теперь раз в 50 часов рестарт, библиотеки jemalloc для распределения памяти у нас стоит, подскажите как ещё можно повлиять на проблему.
Click to expand...
Если периодический рост очередей декодинга сохранился, это значит, что проблема не решена до конца. Если Вы выполнили все рекомендации из этого поста, значит, необходимо далее снижать нагрузку на этот сервер, например, до 60 энкодеров.
Artem_DevOps said:
И второй вопрос если вводить ещё один Transcoder сервер можете порекомендовать наиболее оптимальный процессор для Transcoder сервер
Click to expand...
Мы успешно тестировали транскодинг на Intel Xeon, но желательно не Gold и не Platinum. Количество физических ядер рассчитывается. исходя из следующих требований: 2 ядра для кодирования одного потока 1080p, 1 ядрo для кодирования двух потоков 720p или трех потоков 480p, плюс запас в 20%.
 
A

Artem_DevOps

New Member
Добрый день, ввели ещё один транскодер (CPU: 2x Intel Xeon Gold 6230R
Memory: 256GB) уменьшили возможное количество стримов до 55, более ошибок в логах не наблюдаем, но качество стримов не улучшилось, пикселение и другие дефекты остались.

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

Max

Administrator
Staff member
Artem_DevOps said:
но качество стримов не улучшилось, пикселение и другие дефекты остались.
Click to expand...
Если производительности транскодеров теперь хватает (а ее должно хватать, раз не растут очереди декодирования, т.е. процессорные ядра загружены более-менее равномерно и успевают закодировать картинки потоков), то проблема может быть с качеством каналов публикации входящих потоков. В статистике, которую Вы присылали ранее, в основном публикации 1080p. Как быстрое решение, попробуйте переключиться на TCP при публикации WebRTC:
Code: 
session.createStream({
    name: streamName,
    display: localVideo,
    ...
    transport: "TCP"
}).publish();
Это поможет исключить потери.
Также поможет ограничение битрейта публикации, например
Code: 
session.createStream({
    name: streamName,
    display: localVideo,
    ...,
    constraints: {
         video: {
              width: 1920,
              height: 1080,
              minBitrate: 1000,
              maxBitrate: 2000
         },
         audio: true
    }
    ...
    transport: "TCP"
}).publish();
Кроме того, в профиле транскодирования (файл cdn_profiles.yml на Edge серверах) также нужно явно указать битрейт, например
Code: 
 -720p:
  audio:
    codec : opus
    rate : 48000
  video:
    height : 720
    bitrate : 1500
    gop : 50
    codec : h264
Рекомендуем также контролировать метрики публикуемых на Origin сервере потоков по REST API или в формате Prometheus. Рост метрик VIDEO_LOST, VIDEO_NACK говорит о потерях на канале, снижение битрейта VIDEO_RATE говорит о недостаточной пропускной способности. Для определенных клиентов, где эти проблемы сохраняются, рекомендуем снизить разрешение/битрейт публикации, если клиент не может сменить канал (например, переключиться с 4G на Wi-Fi, с Wi-Fi на проводную сеть)
Artem_DevOps said:
Руководство очень негативно реагирует на сложившуюся ситуацию, рассматривает варианты перейти на другое решение. По этой причине скажите есть ли возможность оперативно организовать поддержку непосредственно наших серверов, подключиться проверить конфигурацию и попытаться найти возможные причины не стабильной работы?
Click to expand...
Наиболее часто встречающиеся причины снижения качества и способы их решения приведены выше.
Чтобы проверить конфигурацию серверов, от Вас потребуются:
- SSH доступы к серверам Origin, Transcoder, Edge
- доступы к web-интерфейсу WCS серверов для публикации/проигрывания тестовых потоков
Доступы предоставьте, используя эту форму.
 
You must log in or register to reply here.
Top