Непонятные краши сервера 5.2

R

Ras2607

Member
Здравствуйте!
Пробовали провести реальное мероприятие после обновления до 5.2
Ранее все тесты показали отличную работу.
Но при подключении более 70 зрителей к одному ведущему весь медиа-сервер каждый раз отваливался.
Думали может сервер не тянет, даже быстренько сменили его аж до 8 ядерного с 32гб ram
Но ничего не изменилось - падения продолжились.
Пришлось оперативно возвращать версию 5.0 - она работает стабильно.

Вопрос - как узнать в чем была причина падений?
в папке logs есть несколько файлов, по времени создания подходящих к времени падения сервера, но какой-то понятной информации там не разобрали. Вроде не хватает каких-то ресурсов, но не ясно каких и как надо переконфигурировать сервер.

Прикладываю все файлы, появившиеся за сегодня.
 

Attachments

Max

Max

Administrator
Staff member
Добрый день.
Мы работаем над этой проблемой в рамках внутреннего тикета WCS-2509. К сожалению, краши воспроизводятся у считанного числа клиентов, но пока нам не удалось их воспроизвести в лабораторных условиях. Поэтому для того, чтобы найти причину, просим описать подробно Ваш кейс:
1. Какой поток публиковал ведущий: технология, кодеки, параметры, используемое ПО (например RTMP H264+AAC 720p 30fps из OBS Studio или WebRTC H264+opus 720p 30fps из Chrome)? Транслировался ли экран? Сколько было ведущих одновременно?
2. Каким образом зрители забирали поток: WebRTC в браузере, HLS, RTMP, RTSP, изменялось ли разрешение картинки по сравнению с публикацией (например, публиковали 720p, зритель заказывал 480p)
Вы предоставили логи сборщика мусора (Garbage Collector) Java, он работал штатно. Пожалуйста, вышлите все логи из каталога WCS_HOME/logs, в особенности если там были файлы вида error*.log, а также все файлы конфигурации сервера WCS_HOME/conf на support@flashphoner.com. Если описание кейса содержит конфиденциальную информацию, его также лучше выслать почтой.
В идеале, желательно получить SSH доступ к Вашему серверу и воспроизвести проблему с участием наших инженеров по согласованию.
В продакшне рекомендуем использовать пока сборку 5.2.477.
 
R

Ras2607

Member
Отвечаю по пунктам:

1. проводилось обучающее мероприятие. мы используем для этого roomAPI
трансляция велась через Chrome на windows 10.
показ рабочего стола через ваш плагин, переделанный только под наш домен + микрофон.
технически реализация достаточно похожа на Ваш демо-пример Two Way Video Chat
Ведущий был только один.
Так же была включена запись.
Code: 
video: {
                width: 1366,
                height: 768,
                frameRate: 10,
                quality: 10,
                type: "screen"
}

2. Поток отдавался как есть, без транскодинга. Все зрители использовали так же Chrome, причем строго десктопную версию.
Этот момент отслеживается на стадии подключения. Мультиплатформенность нам не нужна, важнее стабильность, поэтому все зрители принудительно используют хром.

3. Да, уже разобрались что это не те логи. Логов вида error*.log ни одного нет.
Следы падения нашли в папке server_logs. Он обрывается как раз в том время, как мы зафиксировали очередное падение. Отправил его на почту.
Файлы конфигурации так же добавил в письмо.

Я вчера весь день пытался со своей стороны понять в чем причина.
Обнаружил, что нагрузочное тестирование с использованием другого сервера через приложение Console не дает крашей и все работает стабильно.
Пробовал разные конфигурации сервера (не забывая менять -Xmx и -Xms). Даже на сервере с 1 ядром и 2гб рам запускал вплоть до 100 зрителей. Работать с системой конечно было нельзя, все тормозило и висло, но сервер не крашился. Так что обычные тесты воспроизвести проблему не смогли.

В общем кейс сводится к следующему:
Сборка 5.2.497
Конфигурация разная, максимально проверяемая 8 ядер+32гб ram
Работа через roomAPI, показ рабочего стола+микрофон+запись, более 70 зрителей - краш сервера без логов падения.
Отваливается все. Помогает только вызов команды restart.
 
Last edited:
Max

Max

Administrator
Staff member
Спасибо за подробное пояснение. Нам удалось воспроизвести проблему в нагрузочных тестах с включенной записью потока. Будем разбираться. В качестве временного решения рекомендуем выставить настройку
Code: 
use_fdk_aac=false
либо, если это не поможет, использовать сборку 5.2.477, с которой данная проблема не воспроизводится.
 
Max

Max

Administrator
Staff member
Добрый день.
Проблема с молчаливым крашем сервера при кодировании потока исправлена в сборке 5.2.515. Пожалуйста, обновите сервер и попробуйте.
Если краши без создания логов ошибок снова будут воспроизводиться, необходимо собрать вывод сервера в stdout, запустив его следующим образом:
Code: 
cd /usr/local/FlashphonerWebCallServer/bin
./webcallserver start standalone > /usr/local/FlashphonerWebCallServer/logs/stdout.log 2>&1 &
 
R

Ras2607

Member
Обновились. Первоначальные тесты ошибок не показали. Но реально будет понятно только на следующем мероприятии, когда более 70 человек присоединится. Если вылеты повторятся - обязательно сообщу.
 
Max

Max

Administrator
Staff member
Вы можете провести аналогичный тест, не дожидаясь мероприятия:
1. Опубликовать поток ведущего, полностью имитируя его действия (т.е. если идет переключение экран-камера, его тоже необходимо делать)
2. Включить запись потока
3. Нагрузить сервер 70 и более подписчиками с другого сервера, используя REST API. Пример скрипта, выполняемого на другом WCS сервере:
Code: 
for ((j = 1; j < $PULL_COUNT; j++))
do
      # Забираем поток необходимым числом подписчиков
      curl --data "{\"uri\":\"ws://$WCS_ADDRESS:8080\",\"remoteStreamName\":\"test-speaker\",\"localStreamName\":\"subscriber${j}\"}" -X POST -H 'Content-type: application/json'  -s http://localhost:8081/rest-api/pull/pull >/dev/null 2>&1
done
# Ждем заданное время (подписчики смотрят вебинар)
sleep $WAIT_PULL
for ((j = 1; j < $PULL_COUNT; j++))
do
      # Останавливаем каждого подписчика
      curl --data "{\"uri\":\"ws://$WCS_ADDRESS:8080/websocket\",\"remoteStreamName\":\"test-speaker\",\"localStreamName\":\"subscriber${j}\"}" -X POST -H 'Content-type: application/json'  -s http://localhost:8081/rest-api/pull/terminate >/dev/null 2>&1
done
4. Добавить как минимум одного "реального" зрителя (т.е. играть поток с сервера с использованием Вашей реализации фронт- и бэкенда.
При этом тестируемый WCS необходимо запустить с сохранением stdout.log, как описано здесь.
Проблема, которую мы исправили, воспроизводилась при работающем транскодировании потока на сервере. Транскодирование может включаться, например, при записи потока на сервере (транскодинг звука), либо при воспроизведении с другим кодеком (публикуем как H264, играем как VP8) или явно заданными параметрами потока (размер, quality, bitrate, fps). Проверить наличие транскодинга можно на странице статистики во время работы сервера
Code: 
http://$WCS_ADDRESS:8081/?action=stat
в секции native_resources будет информация о декодере и энкодере (пример для транскодинга видео)
Code: 
-----Native Resources-----
native_resources=28451152,FFDecoderNative:H264/FFMPEG,92555;139673437692704,NENC:H264/OPENH264,101
native_resources.audio_codecs=0
native_resources.audio_resamplers=0
native_resources.video_transcoders=0
native_resources.video_decoders=1
native_resources.video_encoders=1
native_resources.writers=0
 
You must log in or register to reply here.
Top