Падает возможность делать запись

После не определенных количеств записей возможность это сделать пропадает. На вкладке Stream Recording нажимаешь на кнопку и пишет что коннектится. На этом весит. В истории записей висит 10 коннектов и все. Запись не ведется пока не перезагрузишь сервис.
 

Max

Administrator
Staff member
Добрый день.
Дайте пожалуйста номер версии сервера
WCS_HOME/conf/WCS.version
и последние логи из папки WCS_HOME/logs/server_logs
Логи нужны за последние несколько часов тестирования.
Code:
cd WCS_HOME/logs/server_logs
ls -lt
Отсортировать логи по времени можно этой командой.
 

Max

Administrator
Staff member
Для того, чтобы мы могли воспроизвести Ваш тест, необходимо уточнить методику тестирования, что именно Вы делали, по шагам, например:
1. Вошли в веб-интерфейс
2. Перешли на вкладку Stream Recording
3. Нажали на кнопку Start
4. Подождали N секунд
5. Нажали на кнопку Stop
6. Подождали M секунд и т.д.
Кроме того, направьте, пожалуйста, логи за все время теста на запись потоков на почту logs@flashphoner.com, в почте, в отличие от форума, нет ограничений по объему вложений. Также приложите, пожалуйста, Ваш файл настроек сервера WCS_HOME/conf/flashphoner.properties.
 
Логов на 15 гигов. Может какие-то выделить определенные ?
Шаги описать не смогу. В том то и проблема, что нет закономерности. То после 2х записей перестает работать, то день записей нормально происходит и не падает.
Конфиг прилагаю.
 

Attachments

Max

Administrator
Staff member
Чтобы понять Ваш случай и посоветовать что-то определенное, нам нужно знать Ваши действия. Например, каким именно образом Вы тестируете запись:
1. Только из примера Stream Recording (на который Вы ссылаетесь в исходном сообщении)
2. Пользуетесь вызовами REST API /stream/startRecording, /stream/stopRecording
3. Из своего веб-приложения на основе примеров и исходных текстов
Или это вообще не тест, у Вас эта функция использовалась в продакшене и перестала работать? Тогда необходимо знать Вашу технологическую цепочку (call flow): какие именно потоки пишутся (видео+аудио или только аудио), по какой технологии захватываются (WebRTC, RTMP), потоки только записываются или куда-то раздаются, что затем делается с записями? Т.е. подробное описание Вашего случая применения.
Пока это неизвестно, мы можем уточнить только вопросы общего характера:
1. Воспроизводится ли поведение, если обновить WCS до последней доступной версии (на данный момент это 5.1.3460)?
2. Есть ли место на диске для файлов записи?
3. Когда запись останавливается, работает ли в этот момент сервер? Проверить это можно командой
Code:
ps aux | grep WebCallServer
Логи нужны на момент остановки записи и за предыдущие несколько часов.
 
Версию обновил.
По идее я словил ошибку. Весят 3 стрима со статусом PENDING, после того как поставили запись и шеринг экрана. Ошибка в логах такая :
ERROR StunDatagramSocket - Stun receiver udp/31124 Incoming buffer exhausted!
 

Max

Administrator
Staff member
Правильно ли мы понимаем, что ошибка воспроизводится и на новой версии? Если так, то опишите, пожалуйста, максимально подробно условия воспроизведения и предоставьте логи, подготовленные по этой инструкции.
 
Ошибку воспроизвести специально не удается. Она произволно происходит.
По этапам - Это запустили стрим а потом запустили скриншоты и уже там выдало FAILED
Вот логи что есть на тот момент
Screenshot from 2018-08-16 16-32-03.png Screenshot from 2018-08-16 16-31-43.png
 

Attachments

Last edited:

Max

Administrator
Staff member
Из предоставленного скриншота видно, что проблема возникает не на этапе записи, а при публикации потока. К сожалению, предоставленный фрагмент лога к предоставленным скриншотам не имеет никакого отношения, поэтому по этим данным проблему диагностировать затруднительно.
Выше Вы упоминали, что ранее в логах встречалась ошибка
ERROR StunDatagramSocket - Stun receiver udp/31124 Incoming buffer exhausted!
Такая ошибка возникает при переполнении буферов UDP сокетов, что, в свою очередь, может быть результатом работы сборщика мусора (Garbage Collector).
Попробуйте сделать следующее:
1. Выделить больше памяти под Java heap (рекомендуемый объем - 1/2 оперативной памяти сервера) в файле WCS_HOME/conf/wcs-core.properties, например, при объеме RAM 32 Гб
Code:
-Xmx16g
-Xms16g
2. Оптимизировать работу сборщика мусора в файле WCS_HOME/conf/wcs-core.properties
Code:
#Disable heuristic rules
-XX:+UseCMSInitiatingOccupancyOnly

#Reduce Old Gen threshold
-XX:CMSInitiatingOccupancyFraction=70

# Use System.gc() concurrently in CMS
-XX:+ExplicitGCInvokesConcurrent

# Disable System.gc() for RMI, for 10000 hours
-Dsun.rmi.dgc.client.gcInterval=36000000000
-Dsun.rmi.dgc.server.gcInterval=36000000000
3. Настроить буферы UDP сокетов в файле WCS_HOME/conf/flashphoner.properties
Code:
rtp_receive_buffer_size=13107200
rtp_send_buffer_size =13107200
4. Настроить системные очереди
Code:
ip link set txqueuelen 2000 dev eth0
 

Max

Administrator
Staff member
При подобном поведении системы нам очень многое могут подсказать, в направлении тюнинга, отладочные логи клиентов. Поэтому просим собрать отчет об ошибке по этой инструкции и направить на logs@flashphoner.com
Ваш кейс Вы также можете описать в письме, если по какой-либо причине не хотите описывать его на форуме.
 
Ошибка все так-же не зависимо ни от чего появляется. 15-20 раз включить запись стрима и выключить и она появляется. Подумал увелисить rtp_receive_buffer_size но в документации оно позицеонируется как integer (65k). Как тогда может работать такое значение что вы мне дали (13107200) ?
 

Max

Administrator
Staff member
В документации указано значение по умолчанию опции rtp_receive_buffer_size. Оно может быть увеличено, значения были предложены в качестве примера.
Пожалуйста, выполните рекомендации по тонкой настройке с этой страницы. Если это не помогает, и проблема воспроизводится, соберите отчет об ошибке по этой инструкции. Если с этим возникают какие-либо затруднения, предоставьте SSH доступы к Вашему серверу на support@flashphoner.com, наши специалисты посмотрят.
 

Max

Administrator
Staff member
Продвижения могли бы быть успешнее, если бы Вы приложили к логам описание: как тестировали (какие примеры и скрипты использовали), какой поток публиковали (WebRTC, RTMP, что-либо еще). Пока можно только сказать, что по предоставленной информации проблема скорее в публикации потока, чем в его записи.
 
Тестирование проводилось в демо предоставленное с сервисом. Ничего не менялось в скриптах (использовались исходные из коробки). Запись происходила с вкладки Stream Recording. Какой там поток не написано , но полагаю WebRTC. Проблема возникает если в течение некого времени (не определенное. от 1й минуты до 15) включать стрим на запись а потом стопить через секунд 20. Иногда перезагружать страницу. Если надо еще какие-либо описания, скажите.
 

Max

Administrator
Staff member
На тестовых серверах по данной методике проблема не воспроизводится. Если наши специалисты не смогут локализовать проблему по логам, возможно, потребуется предоставить SSH доступ к Вашему серверу. Сейчас мы работаем над некоторыми исправлениями в части записи и транскодирования потока, возможно, в Вашем случае это поможет.
 

Max

Administrator
Staff member
На тестовых серверах по данной методике проблема не воспроизводится. Если наши специалисты не смогут локализовать проблему по логам, возможно, потребуется предоставить SSH доступ к Вашему серверу. Сейчас мы работаем над некоторыми исправлениями в части записи и транскодирования потока, возможно, в Вашем случае это поможет.
 
Top