Нагрузка на сервер

pride · Nov 16, 2017

Здравствуйте! Тестировали вчера трансляции.
При 8-ми транслирующих через RTMP и Примерно 10-15 принимающих (WebRTC).
На сервер наложилась огромная нагрузка, стримы начали повисать, периодически отпадать.
Логи огромные поэтому отправил доступ по SSH на logs@flashphoner.com (Сервер не задействован совсем)

И объясните пожалуйста как и в каких случаях происходит перекодировка RTMP -> WebRTC / WebRTC->RTMP

Max · Nov 16, 2017

Доступы получили. Сервер проверим.

И объясните пожалуйста как и в каких случаях происходит перекодировка RTMP -> WebRTC / WebRTC->RTMP

Транскодинг включается, если не совпадают кодеки.
На RTMP всегда кодек H.264.
На WebRTC vp8 или h.264
Приоритет для WebRTC указывается в flashphoner.properties
Например так будет транскодинг при трансляции из RTMP в WebRTC

Code:

codecs=opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,vp8,h264,flv,mpv

Так не будет:

Code:

codecs=opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,h264,vp8,flv,mpv

Еще транскодинг будет, если вы явно задаете разрешение при воспроизведении

Code:

session.createStream({constraints:{audio:true,video:{width:640,height:480}}}).play()

В этом будет транскодинг с рескейлингом в указанное разрешение.
Поэтому на воспроизведении разрешение лучше не указывать чтобы избежать транскодинга.

Max · Nov 17, 2017

Добрый день

Судя по логам был deadlock.
Его исправили в сборке 2565 (последняя 2566)
Поэтому нужно обновиться до 2566 по ветке wcs5_streaming_threads

Code:

service webcallserver update

У конкретно вашего сервера есть специфика / баг с биндингом портов.
В логах много соответствующих warning-ов. Хотя конфигурация выглядит правильной.
На других видеть такого не приходилось. Поэтому есть смысл проверить на другом сервере такой же мощности.
Если дадите другой сервер, поможем с установкой / переносом, если он потребуется.

pride · Nov 20, 2017

Max said:
Добрый день

Судя по логам был deadlock.
Его исправили в сборке 2565 (последняя 2566)
Поэтому нужно обновиться до 2566 по ветке wcs5_streaming_threads

Code:

service webcallserver update

У конкретно вашего сервера есть специфика / баг с биндингом портов.
В логах много соответствующих warning-ов. Хотя конфигурация выглядит правильной.
На других видеть такого не приходилось. Поэтому есть смысл проверить на другом сервере такой же мощности.
Если дадите другой сервер, поможем с установкой / переносом, если он потребуется.

А не может это быть связанно с параноидальной строгостью CentOS?

Max · Nov 20, 2017

А не может это быть связанно с параноидальной строгостью CentOS?

Мы как правило сами используем CentOS и в сапорте приходилось видеть около сотни инсталляций с CentOS, но на тих такой проблемы не было.

pride · Nov 21, 2017

Max said:
Мы как правило сами используем CentOS и в сапорте приходилось видеть около сотни инсталляций с CentOS, но на тих такой проблемы не было.

Вернули debian на сервер, обновили WCS.
Вроде как отпустила нагрузка, да вот только жуткие тормоза при просмотре стримов. Все рывками, причем выборочно

pride · Nov 21, 2017

ip =
ip_local =
port_from =30000
port_to =31000
media_port_from =31001
media_port_to =32000
waiting_answer =60
user_agent =WCS5
balance_header =balance
cost_header =cost
video_enabled =true
domain =
outbound_proxy =
outbound_port =
log_level =5
enable_context_logs =false
rtp_activity_detecting =true,60
sip_msg_listener =com.flashphoner.sdk.sip.ChangeCallIdListener
call_record_listener =com.flashphoner.server.client.DefaultCallRecordListener
dtmf =rfc2833
auto_login_url =/usr/local/FlashphonerWebCallServer/conf/account.xml
get_callee_url =/usr/local/FlashphonerWebCallServer/conf/callee.xml
codecs =opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,h264,vp8,flv,mpv
codecs_exclude_sip =mpeg4-generic,flv,mpv
codecs_exclude_streaming =flv,telephone-event
codecs_exclude_sip_rtmp =opus,g729,g722,mpeg4-generic,vp8,mpv
on_record_hook_script =on_record_hook.sh
rtmp_transponder_stream_name_prefix =
webrtc_cc2 = true
webrtc_cc2_сс = false
webrtc_cc2_bitrate_overuse_event_threshold=0.20
webrtc_cc_max_bitrate = 2000000
webrtc_cc_min_bitrate = 30000
suppress_audio=true

Max · Nov 22, 2017

Опишите / покажите на скриншотах как именно отправляете RTMP потоки на сервер. Какие потоки (разрешение, битрейт, кодеки).
И как именно их забираете.
Тестировать лучше со стандартным плеером Embed Player чтобы исключить проблемы интеграции.
Мы проведем похожие тесты с вашим сервером. Пришлите снова доступ на logs@flashphoner.com

только жуткие тормоза при просмотре стримов

1. Проверьте полосу между источником стримов и сервером.
Возможно потоки просто не входят в эту полосу.
2. Тоже самое с полосой между сервером и браузером, который воспроизводит стрим.
Достаточно ли полосы чтобы принять поток в исходном битрейте.

Max · Nov 23, 2017

Добрый день.
Доступы получили. Но так и не получили описания, как именно формируется нагрузка и как нам это повторить.

pride · Nov 25, 2017

Поток отправляем по RTMP, кодек h264, плавающий битрейт.

OBJECT:
{
"nodeId" : "DwSdRKPE9BrbUW8sDhRZ8jd2ScW3tQR9@00.00.00.00",
"appKey" : "streamFlash",
"sessionId" : "7458ef9e-abb9-4430-80aa-539990cf2f53",
"mediaSessionId" : "2c70b385-3c8f-4585-a3ea-866073b3620a",
"name" : "146653",
"published" : true,
"hasVideo" : false,
"hasAudio" : true,
"status" : "PUBLISHING",
"audioCodec" : "speex",
"videoCodec" : "H264",
"record" : false,
"width" : 0,
"height" : 0,
"bitrate" : 0,
"quality" : 0,
"createDate" : 1511265692225,
"mediaProvider" : "Flash",
"history" : false
}

Смотрим WEBRTC с теми же параметрами:

OBJECT:
{
"nodeId" : "DwSdRKPE9BrbUW8sDhRZ8jd2ScW3tQR9@00.00.00.00",
"appKey" : "stream",
"sessionId" : "/00.00.00.00:50734/00.00.00.00:8080",
"mediaSessionId" : "d2a891a0-ceb3-11e7-be93-e94f669359cf",
"name" : "146653",
"published" : false,
"hasVideo" : true,
"hasAudio" : true,
"status" : "PLAYING",
"audioCodec" : "opus",
"videoCodec" : "H264",
"record" : false,
"width" : 0,
"height" : 0,
"bitrate" : 0,
"quality" : 60,
"createDate" : 1511265741397,
"mediaProvider" : "WebRTC",
"history" : false,
"custom" : {
"user" : "34",
"token" : "8888",
"broadcast" : false
},
"origin" : "http://------------"
}

Max · Nov 26, 2017

RTMP поток можно отправить разными способами.
1. Flash Player
2. ffmpeg
3. Live Encoder (Wirecast, FMLE)
4. Ре-стриминг с другого сервера, например Adobe AMS, WCS

Какой именно способ используете вы?
С какими настройками?
1. Аудио кодек (Speex, G.711, AAC).
2. FPS.
3. Разрешение.
4. H.264 профиль (Baseline, Main) и Level, например 3.1.

Нам нужно повторить похожую отправку RTMP-потоков и провести схожий тест.
Тогда сможем понять что именно происходит.

Как вариант, можете попробовать добавить настройку в flashphoner.properties

Code:

rtmp_in_buffer_enabled=true

Эта настройка включает буферизацию входящего RTMP видео.

pride · Dec 1, 2017

Поток отправляем Flash Player (с помощью WEBSDK).
Разрешение камеры: 1280х720;

connection.createStream({
name: name,
display: canvas,
custom : {broadcast: '54564')},
cacheLocalResources: true,
receiveVideo: false,
receiveAudio: false,
constraints: {
'video': {
"width": 1280,
"height": 720,
},
'audio': false
}
})

Смотрим :

connection.createStream({
name: name,
display: canvas,
constraints: {video': {}, audio: false}
})

Жуткая нагрузка на процессор.

pride · Dec 1, 2017

Чем больше разрешение камеры, тем сильнее нагрузка на проц.

pride · Dec 1, 2017

Причем неважно чем отправлять. Будь то WebRTC или Flash.

pride · Dec 1, 2017

Заметил в manager.log следующее:

15:43:31,092 ERROR [dispatcherServlet] - http-nio-9091-exec-2 Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request proces
com.flashphoner.server.commons.rmi.operations.exception.ClientNotFoundException
<------>at com.flashphoner.server.rmi.NodeApi.sendData(Unknown Source)
<------>at sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source)
<------>at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
<------>at java.lang.reflect.Method.invoke(Method.java:498)
<------>at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
<------>at sun.rmi.transport.Transport$1.run(Transport.java:200)
<------>at sun.rmi.transport.Transport$1.run(Transport.java:197)
<------>at java.security.AccessController.doPrivileged(Native Method)
<------>at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
<------>at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
<------>at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
<------>at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
<------>at java.security.AccessController.doPrivileged(Native Method)
<------>at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
<------>at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
<------>at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
<------>at java.lang.Thread.run(Thread.java:748)
<------>at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283)
<------>at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260)
<------>at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
<------>at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
<------>at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
<------>at com.sun.proxy.$Proxy118.sendData(Unknown Source)
<------>at sun.reflect.GeneratedMethodAccessor190.invoke(Unknown Source)
<------>at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
<------>at java.lang.reflect.Method.invoke(Method.java:498)
<------>at org.springframework.remoting.rmi.RmiClientInterceptorUtils.invokeRemoteMethod(RmiClientInterceptorUtils.java:71)
<------>at org.springframework.remoting.rmi.RmiClientInterceptor.doInvoke(RmiClientInterceptor.java:364)
<------>at org.springframework.remoting.rmi.RmiClientInterceptor.invoke(RmiClientInterceptor.java:260)
<------>at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
<------>at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:207)
<------>at com.sun.proxy.$Proxy119.sendData(Unknown Source)
<------>at com.flashphoner.server.manager.controller.old_rest.OldRestCallbackController.handleRequest(OldRestCallbackController.java:65)
<------>at sun.reflect.GeneratedMethodAccessor188.invoke(Unknown Source)
<------>at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
<------>at java.lang.reflect.Method.invoke(Method.java:498)
<------>at org.springframework.web.method.support.InvocableHandlerMethod.invoke(InvocableHandlerMethod.java:215)
<------>at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:132)
<------>at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:104)
.....

pride · Dec 4, 2017

6 публикующих - 6 смотрящих.
0,9 LA.
При 1,7 LA начинает сыпать картинку.
А до 1,7 LA еще примерно 7 стримеров.

Max · Dec 4, 2017

Пока идея такая что включается транскодинг, когда вы передаете при воспроизведении:

Code:

connection.createStream({
name: name,
display: canvas,
constraints: {video: {}, audio: false}
})

Попробуйте так:

Code:

constraints: {video: true, audio: false}

Если вы передаете video:{}, то может передаться ширина высота 0x0, а если явно передать ширину и высоту, начинается транскодинг.

pride · Dec 4, 2017

Да но в таком случаи, паблишер будет вещать в малом разрешении 320х240. И ему без разницы что камера поддерживает другие разрешения))

Max · Dec 5, 2017

Мы проверили сборку: 2613
IE 11 / Chrome 62: Two-way Streaming
Т.е. IE 11 отправляет поток по RTMP, Chrome 62 играет по WebRTC.
constraints: {video: {}, audio: false} для подписчика
транскодинга нет
Поток: 1280x720: DO-сервер: серверный процесс, CPU 16 - 25%
Т.е. нагрузка достаточно низкая.
Попробуйте опубликовать поток из нашего стандартного примера Two Way Streaming с выставлением разрешения 1280x720 для публикации.
И проиграть с этим же стандартным примером с выставлением constraints: {video: {}, audio: false}
Если все будет работать нормально, возможно проблема в старой версии Web SDK, которую вы тестирукте или в интеграционном коде.
Кроме этого, мы замечали высокую нагрузку при включенном подавлении звука. Попробуйте его отключить
suppress_audio=false

pride · Dec 16, 2017

Max said:
Добрый день

Судя по логам был deadlock.
Его исправили в сборке 2565 (последняя 2566)
Поэтому нужно обновиться до 2566 по ветке wcs5_streaming_threads

Code:

service webcallserver update

У конкретно вашего сервера есть специфика / баг с биндингом портов.
В логах много соответствующих warning-ов. Хотя конфигурация выглядит правильной.
На других видеть такого не приходилось. Поэтому есть смысл проверить на другом сервере такой же мощности.
Если дадите другой сервер, поможем с установкой / переносом, если он потребуется.

Приобрели новый сервер. Помогите пожалуйста с установкой и конфигурацией. Доступы отправили на logs@flashphoner.com

Нагрузка на сервер

Member

Administrator

Administrator

Member

Administrator

Member

Member

Administrator

Administrator

Member

Administrator

Member

Member

Member

Member

Member

Administrator

Member

Administrator

Member