Сервер лег под нагрузкой

[Aleksey]

Это при множественном просмотре одного стрима или нескольких?

 

[Alex Vorona]

На своих пока получилось разогнать до 600 Mbps

Вы получили NOT_ENOUGH_BANDWIDTH на большинстве потоков в ваших тестах?

 

[Aleksey]

Для теста мы запускали 1 стрим и подключались к нему через chrome headless с 3х физических серверов, с 12 VM aws и нескольких обычных chrome сессий из офиса. Когда утилизация исходящего начинает превышать 300-350Mbps, в лог падают эти сообщения для всех IP адресов клиентов и в обычном chrome видна задержка видео до 10 секунд, дальше видимо что-то падает в приложении и видео становится 4 кадра в секунду и видны большие потери пакетов по chrome://webrtc-internals, они растут лавинообразно.
Если в этот момент запустить еще один стрим, то он воспроизводится нормально в других вкладках chrome. Видмо с несколькими стримами можно разогнать сервер до 1Gbps, но с одним стримом такого не получается.

 

[Alex Vorona]

Наблюдали аналогичную ситуацию как на бета-тесте живых клиентов так и на синтетике,в синтетике только клиентом использовали flashphoner https://forum.flashphoner.com/threads/Нагрузочное-тестирование-webrtc.11138/, у него нагрузка ощутимо ниже чем у chrome, а значит на том же "клиентском" железе можно получить больше. Как временный work-around для размазывания нагрузки по серверам, может подойти межсерверный webrtc, но хочется получать хотя бы 800-900Мбит с 1Гбит сервера.

 

[Max]

Это при множественном просмотре одного стрима или нескольких?

Тестировали один.

Вы получили NOT_ENOUGH_BANDWIDTH на большинстве потоков в ваших тестах?

Скорее да. Именно это сообщение в логах не искали, но на тестах видели значительный рост NACK на плеере, который говорит о потерях. А при потерях высылается N_E_B.



Сейчас делаем некоторые оптимизации по памяти и тесты для выявления узких мест. Уже есть некоторые улучшения.
Как только появятся проверенные результаты, отпишем.

 

[Aleksey]

есть какая-то новая информация по этой проблеме?
возможно сроки появления нового билда?

 

[Max]

Пока продолжаем искать узкое место. Тестами удалось сузить область поиска. Надеемся на этой неделе получить результаты.
Если что-нибудь станет известно по срокам, тут же сообщим.

 

[Aleksey]

Получилось найти самое узкое место?

 

[Max]

Доборый день.

Обнаружили 2 узких места, сильно влияющих на работу под нагрузкой.
1. Генерировалось много мусора при подсчете входящего битрейта.
2. Во время работы сервера могут быть вспышки трафика, которые связаны с неравномерностью входящего битрейта WebRTC. Эти вспышки можно частично подавлять с помощью регулировки буферов сервера и системных буферов и очередей Linux.

В результате провели нагрузочные тесты с сервером 1 x Xeon(R) CPU E5-1650 v2 @ 3.50GHz, 6 ядер, 12 потоков.
По результатам получили около 1000 подписчиков, с утилизацией канала около 800 Mbps и ровным воспроизведением.

Тюнинг WCS
1. Установка сборки 2544 с фиксами по генерации мусора.

service webcallserver update 2544

2. Настройки heap в файле wcs-core.properties

-Xms8g -Xmx16g

3. Настройки GC в файле wcs-core.properties

-XX:+UseConcMarkSweepGC -XX:NewSize=1024m

4. Настройки UDP буферов WCS-сервера в конфиге flashphoner.properties

rtp_receive_buffer_size=13107200

Значение не может быть больше чем указано в /proc/sys/net/core/rmem_max

rtp_send_buffer_size =13107200

Значение не может быть больше чем указано в /proc/sys/net/core/wmem_max
5. Выставить кодек VP8 в приоритет и зажать битрейт входящего потока в конфиге flashphoner.properties

webrtc_cc_min_bitrate =400000
webrtc_cc_max_bitrate =500000
codecs =opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,vp8,flv,mpv

Тюнинг Linux
Поскольку используется UDP транспорт нужно убедиться что пакеты на выходе не теряются и возможно поднять буфер командой:

ip link set txqueuelen 2000 dev eth0

Для проверки потерь под нагрузкой можно воспользоваться dropwatch утилитой:
- dropwatch -l kas
- start

Таким образом, текущие тюнинги направлены на уменьшение разброса битрейта и на увеличение буфферов / очередей для поглощения вспышек битрейта. В следующих оптимизациях у нас запланировано сглаживание таких вспышек на уровне кода или тюнингом очередей в Linux, и несколько других идей по улучшению производительности, которые планируем отработать на ветке wcs5_monitoring.

 

[KonstantinK]

как вы тестировали?
один входящий поток и 1000 плееров ?
иа какая нагрузка на CPU получилась?

 

[Max]

как вы тестировали?

Это был синтетический тест по этой инструкции.
Один сервер раздавал потоки, другой их забирал.

один входящий поток и 1000 плееров ?

да, 1000 подписчиков с утилизацией канала около 800 Mbps.

и какая нагрузка на CPU получилась?

1 ядро процессора из 6.

 

[Alex Vorona]

Судя по такой низкой нагрузке на CPU следующая планка - 8Gbit на 10Gbit интерфейсе

 

[Aleksey]

Здравствуйте,
Есть какие-то новости по новому билду?

 

[Max]

Есть какие-то новости по новому билду?

Если вопрос про это:

В следующих оптимизациях у нас запланировано сглаживание таких вспышек на уровне кода или тюнингом очередей в Linux

Пока в работе. Если интересно, создайте пожалуйста отдельный топик. Мы отпишем когда по этим оптимизациям будут движения.

 

[Alex Vorona]

А как подкрутить webrtc pull, чтобы сервер мог больше 250 потоков забирать? Очень похоже на лимит. Также наблюдаю картину, что соединения переходят в NOT_ENOUGH_BANDWIDTH через небольшое время и сервер начинает есть заметно больше CPU.
Начало как-то так - 200-250%cpu

   5     "status": "NOT_ENOUGH_BANDWIDTH",
  4     "status": "PENDING",
486     "status": "PLAYING",
  1     "status": "PUBLISHING"

конец 300-400% cpu сервер и 400-500% manager

484     "status": "NOT_ENOUGH_BANDWIDTH",
  1     "status": "PUBLISHING",

Ещё немного подождал, и сервер и менеджер начали плодить потоки с соответствующим увеличением потребления CPU. Сервер с 8тыс потоков поднялся до 13тыс, менеджер с 500 до 5000. Сервер monitoring 5.0.2558, 2 клиента по 250 потоков streaming_threads 5.0.2560

 

[Alex Vorona]

Если сервер взять streaming_threads 5.0.2560, то "пложения" тредов и перегрузки не наблюдается.
11тыс тредов сервер и ~200-400 менеджер. Утилизация канала 350-400мбит, забираю поток 2.5мбита

723     "status": "NOT_ENOUGH_BANDWIDTH",

то есть средний битрейт в районе 0.5мбита

В таком состоянии, похоже после включения rtmp репаблишинга, java-сервер,несмотря на -Xms6g -Xmx10g, начал есть по 4GB памяти в минуту и на 3-й минуте RAM закончилась и сервер засвопился. java-сервер в пике получил 14GB RAM и 7GB swap.

 

[Max]

Спасибо. Сравним на своих тестах. По результатам отпишем.
На streaming_threads 5.0.2560 визуально на воспроизведении потока какие-то проблемы были? Или только
NOT_ENOUGH_BANDWIDTH ?

 

[Alex Vorona]

На streaming_threads 5.0.2560 визуально на воспроизведении потока какие-то проблемы были?

Да, при достижении ~350+Мбит воспроизведение начинает сильно спотыкаться. Проверял на шаринге экрана с плавающим битрейтом до 2.5Мбит на 170 пулл-стримах. Пока входящий битрейт низкий и исходящий трафик небольшой - проблемы нет. Когда входящий битрейт ~2.5мбит(не всплеск, а постоянно) - воспроизведение спотыкается. При этом же трафике я запускаю iperf udp на другой сервер, добавляя 500мбит к существующим 350-400 от Flashphoner, и потери в iperf менее 0.01%. Есть смысл попробовать 2 Flashphoner на 1 сервере, разнеся их по портам ?

 

[Max]

Сейчас тестируем в новой конфигурации, приближенной к вашей. По результатам сообщим.

Есть смысл попробовать 2 Flashphoner на 1 сервере, разнеся их по портам ?

Надежнее тогда разбить сервер на два с помощью виртуализации.