Клиенты отваливаются через 10-30 секунд

[alexanderY]

Здравствуйте.
Всё работало несколько дней без сбоев. Вчера у пользователей начались проблемы. Либо дисконнект через полминуты, либо сразу не подключается. На стороне браузера выглядит так:

Spoiler

13:05:08 Mediaserver connected
13:05:08 Mediaserver failed to join room
13:05:08 Mediaserver disconnected
13:05:08 Mediaserver reconnecting...
13:05:10 Mediaserver connected
13:05:11 Mediaserver failed to join room
13:05:11 Mediaserver disconnected
13:05:11 Mediaserver reconnecting...
13:05:13 Mediaserver connected
13:05:13 Mediaserver failed to join room
13:05:13 Mediaserver disconnected
13:05:13 Mediaserver reconnecting...

Reconnecting - реализовал уже я, на случай дисконнекта по каким-то сетевым причинам. Это просто попытка заново подключиться и присоединиться к комнате (connect и join). Короче, вот это всё происходит в цикле, ни разу не подключается дольше, чем на доли секунды.
Баг воспроизводится на демо Streamer. Т.е. подключается, публикует, воспроизводит, и через несколько секунд дисконнект.
CPU 2%, RAM used 2.2Gb из 4Gb.
Прикрепляю логи flashphoner_manager и flashphoner на всякий случай. Из подозрительного заметил только сообщение "POST request for "http://localhost:9091/RoomApp/OnDataEvent" resulted in 409 (Conflict); invoking error handler".

 

[Max]

Добрый день.
Пришлите полные логи за несколько часов на logs@flashphoner.com
или откройте / пришлите доступ по ssh, проверим.

 

[alexanderY]

Выслал.

 

[alexanderY]

Есть ли какие-либо мысли? Я перезагрузил Флэшфонер и теперь при попытке зайти в демо вижу ошибку SSL: https://yadi.sk/i/9RoFn2s93Eiwiv
Подумал, может быть дело в автопродлении нашего сертификата? Допустим, на домен он продлился, но заново в keystore их никто не импортировал.

Проверяю ключи letsencrypt - дата изменения 10 февраля, т.е. не обновлялись в последние пару дней.

 

[Max]

С вашим сертификатом что-то странное.

Так выглядят сертификаты, полученные браузером при коннекте.
Они выданы на этот сайт strifecity.com
Т.е. это либо один из ваших проектов либо еще что-то.
Разберитесь кто слушает на порту 443 и кто отдает эти сертификаты.
По логам пока результатов нет.

 

[alexanderY]

Извините, я вам отправил адрес старого поддомена, на котором раньше работал Флэшфонер.
Новый начинается с wcs5-01. И у него с сертификатом всё в порядке. Демо открывается, но FAILED при попытке опубликовать. https://yadi.sk/i/X1X-HHbr3Ej4wA
P.S. О данном сайте мне ничего не известно категорически.
P.P.S. С доменом strifecity всё ясно, просто наш старый поддомен указывал на старый IP-адрес сервера с Флэшфонером, а там уже другой проект, т.к. тот сервер мы удалили и ушли к другому хостеру. Так что одной странностью меньше.

 

[Max]

Что касается проблем с подключениями.
В логах flashphoner_manager.log видно 409 Conflict.
Это происходит при попытке в один и тот же room сделать join двух пользователей с одинаковыми login
Если пройти выше по логу можно увидеть что у вас часто используется login: 16
Возможно в этом причина ошибки.
Проверьте по вашему коду уникальность логинов.

Попытки частых автоматических ре-коннектов совместно с ошибкой логина, возможно как-то повлияли на сервер.
Попробуйте перезагрузить и провести тест заново.

 

[alexanderY]

16 это логин моего коллеги — он тестирует гораздо чаще меня или других юзеров. Сейчас с ним обсуждали. Конечно, задним числом мы не можем быть ни в чем уверены. Но коллега утверждает, что у него всегда открыта только одна вкладка с определенной комнатой, т.е. множественных коннектов быть не могло.

login указывается в методе Flashphoner.roomApi.connect, параметр username, верно? Если так, то по коду ошибки вроде нет — для каждого юзера там указывается его уникальный id.

Частые реконнекты — спорить не буду. Возможно, но попытка коннекта происходит не чаще одного раза в две секунды. К тому же, установлено ограничение на 5 неуспешных попыток. Если не смогли соединиться 5 раз подряд - больше не пытаемся. То, что видно в первом посте под спойлером, однако, обходит это ограничение по той причине, что событие connect отлавливается, и попытка подключения считается успешной (счетчик неуспешных коннектов сбрасывается на 0). Однако, сразу за этим происходит fail и disconnect.
И последнее — как я писал в посте выше, я перезагрузил Флэшфонер, и всё равно, после этого не работает даже демо из коробки.

 

[Max]

и всё равно, после этого не работает даже демо из коробки

Обычно перезапуск с помощью этой команды помогает:

service webcallserver restart

Редко бывает что при перезапуске не останавливается процесс.
Если вдруг после перезапуска что-то не работает, нужно провести его еще раз по шагам с убийством процессов.
1. Остановить сервер.

service webcallserver stop

2. Проверить остались ли процессы.

ps aux | grep java

3. Убить процессы, если остались

kill PID

где PID - id процесса
4. Еще раз проверить и убить

kill -9 PID

5. После этого можно запускать сервер.

service webcallserver start

На вашем севрере перезапустили и демо работает.
Есть проблема с самым первым стримом на Play после запуска. С ним разбираемся.

 

[alexanderY]

Подтверждаю, сейчас всё работает.
Меня, конечно, больше интересуют точные причины такого поведения. Стоит ли увеличить таймаут до следующего реконнекта?

 

[Max]

Стоит ли увеличить таймаут до следующего реконнекта?

Если соединение не было установлено со второго раза, то что-то уже пошло не так и нет смысла делать реконнекты 5 раз.
Можно каждый раз увеличивать таймаут в два раза.

Меня, конечно, больше интересуют точные причины такого поведения.

Чтобы понять точные причины, нужно его воспроизвести. У нас пока не получается. Видим только что дисконнекты происходят только тогда, когда идут попытки коннектов в одну комнату двух пользователей с одинаковыми логинами.
Если пришлете тест, который воспроизводит эту проблему на стандартном примере / API и нам удастся это повторить, то точную причину можно достаточно быстро найти и исправить.

 

[alexanderY]

Если соединение не было установлено со второго раза, то что-то уже пошло не так и нет смысла делать реконнекты 5 раз.
Можно каждый раз увеличивать таймаут в два раза.

Спорно. На нестабильном канале соединение периодически отваливается . Но через пару попыток восстанавливается. Собственно, только из-за этого сценария и реализовали реконнект. Я-то понимаю, что если проблема на стороне юзера — то мы почти ничего не можем сделать. Но бросать юзеров на произвол судьбы — тоже нехорошо. Юзеры чаще будут винить админов, а не свой коннект. Так что приходится делать такие финты, как тихая попытка переподключиться.
Спасибо за совет насчет таймаута, хорошая мысль.

Если пришлете тест, который воспроизводит эту проблему на стандартном примере / API и нам удастся это повторить, то точную причину можно достаточно быстро найти и исправить.

Понимаю. Сомневаюсь, что на стандартном примере удастся повторить. Особенно, если дело в реконнектах. И учитывая то, что 95% времени всё работает отлично. Код не меняется, но вдруг начинают идти "попытки коннектов в одну комнату двух пользователей с одинаковыми логинами".

Кстати, в каких случаях Флэшфонер считает, что юзер с определенным логином в комнате уже есть? Я имею в виду, нет ли там небольшого промежутка времени, после того, как реальный юзер вышел из комнаты (например, обновил страницу), во время которого Флэшфонер всё ещё может посчитать, будто юзер присутствует? И из-за этого выдавать ошибку. Маловероятно, конечно, но всё же.

 

[Max]

Кстати, в каких случаях Флэшфонер считает, что юзер с определенным логином в комнате уже есть? Я имею в виду, нет ли там небольшого промежутка времени, после того, как реальный юзер вышел из комнаты (например, обновил страницу), во время которого Флэшфонер всё ещё может посчитать, будто юзер присутствует? И из-за этого выдавать ошибку. Маловероятно, конечно, но всё же.

Юзер вычищается из комнаты в двух случаях.
1) Юзер вызывает leave()
2) Сервер видит дисконнект пользователя.

Дисконнект пользователя может быть тоже двух видов:
1) Нормальный дисконнект. Например если юзер закрыл Chrome-браузер.
В этом случае браузер успеет отправить закрывающий Websocket-фрейм и сервер сразу получает информацию о том, что юзер Disconnected.
2) Unexpected дисконнект. Например если реально упало соединение или жестко скрэшился браузер и не успел отправить завершающего фрейма.
В этом случае работают keep alive, которые настроены в конфиге server.properties

keep_alive.algorithm=HIGH_LEVEL
keep_alive.server_interval =5000
keep_alive.probes          =10

Т.е. делается 10 попыток пропинговать браузер, каждая по 5 секунд.
Таким образом коннект продолжает жить 50 секунд и только после этого инициируется Disconnect, который вычищает юзера из Room.
Поэтому вполне вероятно, что проблема вызвана как-раз таким дисконнектом.
И получается что попытки реконнекта не должны быть чаще чем keep_alive.server_interval * keep_alive.probes / 1000
Например если выставить настройки

keep_alive.server_interval =2000 (минимально возможное значение)
keep_alive.probes          =2

То повторные попытки можно начинать только через 4 секунды, а лучше через 5.

 

[alexanderY]

Звучит логично. Думаю, попробуем поменять keep_alive и делать реконнект реже. Понаблюдаем. Большое спасибо.

 

[alexanderY]

Сегодня был большой тест с реальными пользователями. Началось всё достаточно хорошо (у пары юзеров были проблемы на их стороне). Но спустя 10-20 минут начались проблемы.

У нас было 3-4 стримера одновременно и ~20 зрителей. Начались массовые жалобы, сначала на то, что картинка тормозит/пропадает, звук глючит. Потом вообще все отрубалось. Делали полную перезагрузку флэшфонера (с убийством процессов java), и даже потом полную перезагрузку сервера. Всё равно после рестарта, через несколько минут начинались проблемы.

В каталоге Флэшфонера появились файлы error2758 и error8667, я их прикрепляю, вместе с остальными логами. Раньше таких файлов я не видел.

По нагрузке сервера, было более 1 гб свободной памяти, а вот нагрузка на CPU в среднем была 35%, в пике прыгала до 60%. Может и выше, я не смотрел всё время в консоль.

Ссылка на логи - https://yadi.sk/d/ohSqzXFs3Ezdc3

Что планируем дальше делать:

1. В нашей тестовой среде попробуем сэмулировать 20 пользователей с помощью виртуалок. Сейчас у нас только 2 виртуалки с "ботами" и пара реальных машин. Если есть предложения, как проще это сделать, с радостью выслушаю. Потому что заводить 20 виртуалок и управлять ими будет не очень удобно.
2. Попробуем завести 20 ботов в стандартное демо. Если я правильно понимаю, нам нужно взять демо "Conference" и убрать ограничение на максимальное количество участников. И потестить так, будут ли проблемы.

Если есть еще какие-то предложения, как нам выяснять, где зарыта проблема, буду очень рад услышать.

 

[Max]

У нас было 3-4 стримера одновременно и ~20 зрителей. Начались массовые жалобы, сначала на то, что картинка тормозит/пропадает, звук глючит. Потом вообще все отрубалось. У нас было 3-4 стримера одновременно и ~20 зрителей. Начались массовые жалобы, сначала на то, что картинка тормозит/пропадает, звук глючит. Потом вообще все отрубалось.

Возможно был забит канал и в результате началсь такие проблемы.
Какое разрешние видеопотока у вас используется?
Можно ограничить битрейт для всех в конфиге flashphoner.properties

webrtc_cc_min_bitrate=300000
webrtc_cc_max_bitrate=400000

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

В каталоге Флэшфонера появились файлы error2758 и error8667, я их прикрепляю, вместе с остальными логами. Раньше таких файлов я не видел.

Это крэш-файлы, которые говорят что ядро скрэшилось.
Чтобы от них избавиться, рекомендуется использовать следующие настройки:
1. Устновить JDK 1.8 Oracle HotSpot, как описано здесь
2. Отключить декодирование потоков в flashphoner.properties

streaming_video_decoder_fast_start=false

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

В нашей тестовой среде попробуем сэмулировать 20 пользователей с помощью виртуалок. Сейчас у нас только 2 виртуалки с "ботами" и пара реальных машин. Если есть предложения, как проще это сделать, с радостью выслушаю. Потому что заводить 20 виртуалок и управлять ими будет не очень удобно.

У нас есть для этого специальные лоадтесты. Немного позже выложим документацию по их настройке. Суть тестов - мы можем поднять виртуалку Ubuntu без UI и на ней запускать опять же без UI процессы браузера Chrome, который подключается к потокам и тянет видео, потом через указанное в настройках время отключается, тем самым эмулируя работу зрителей.

Если есть еще какие-то предложения, как нам выяснять, где зарыта проблема, буду очень рад услышать.

Основных проблемы видно две
1. Отваливаются зрители при "засорени" канала.
2. Происходит крэш сервера.
Первую можно попытаться решить уменьшением и фиксацией битрейта.
Вторую, временным отключением декодинга.
Мы со своей стороны проведем ряд тестов и посмотрим что можно сделать чтобы улучшить работу сервера.

 

[alexanderY]

Возможно был забит канал и в результате началсь такие проблемы.
Какое разрешние видеопотока у вас используется?

Можно ограничить битрейт для всех в конфиге flashphoner.properties

В конфиге на момент теста ограничений не было, т.е. дефолт. Точные разрешения мне неизвестны, у пользователей обычные вебкамеры. Субъективно, по качеству картинки, не скажу, что какие-то ультра-топовые модели. Обычные бюджетные вебки. Перед следующим тестом внесем изменения в конфиг, конечно.

Это крэш-файлы, которые говорят что ядро скрэшилось.

Крэши из-за высокой нагрузки CPU или Network? Предполагаю, что из-за cpu, раз речь о декодировании.

У нас есть для этого специальные лоадтесты. Немного позже выложим документацию по их настройке. Суть тестов - мы можем поднять виртуалку Ubuntu без UI и на ней запускать опять же без UI процессы браузера Chrome, который подключается к потокам и тянет видео, потом через указанное в настройках время отключается, тем самым эмулируя работу зрителей.

Будет ОЧЕНЬ здорово, если мы сможем поднять у себя такие же виртуалки. Скажите, возможно ли будет поднять 25 таких процессов на одной машине i7 3.4GhZ (4 ядра), 16 gb RAM?

По поводу забивания канала. Вы правы. Если верить atop, в пике у нас было что-то в районе 295 мбит/сек. При этом, хостер нам даёт не жёсткие 100 мбит, т.е. превысить можно (если есть свободный ресурс), но ненамного и ненадолго. Скрин atop незадолго до крэша:
https://yadi.sk/i/NsK1tNBn3FBGNa

Вопрос, откуда могло получиться даже 250 мбит/сек. Просто посчитаем. 25-27 зрителей. Округлим до 30. Три стримера. Пусть у каждого стримера будет 1.3 мбит поток (на самом деле было меньше; как минимум у одного всегда был только звук, без видео). Это 4.2 мбита, умножаем на 30 зрителей. Итого я ожидал увидеть максимум 126 мбит. Пять стримеров это 195 мбит при таких подсчетах. Уже ближе, но всё равно не 295. При этом не стоит забывать, что мы округлили до 30 зрителей.

Либо я сильно ошибся, допустив всего 1.3 мбит на стрим, либо я не знаю.

P.S. Вопрос, корректно ли утверждение, если стример "замьютил" своё видео, его поток, содержащий теперь только звук, будет "занимать" значительно меньше 1 мбита?

 

[Max]

Крэши из-за высокой нагрузки CPU или Network? Предполагаю, что из-за cpu, раз речь о декодировании.

Мы разобрали крэш файлы. Наиболее вероятно случилось следующее.
На каком-то этапе была превышена ширина серверного канала от хостера 100 Mbps, после чего начали сбрасываться пакеты. Когда сбрасываются пакеты, WCS и браузеры начинают запрашивать их досылку, что еще больше нагружает канал сервера. В результате канал был еще больше перегружен - до значений в 250 Mbps и выше, хостер начал еще больше сбрасывать, и т.д. В результате произошел выход WCS уже по оперативной памяти за heap 3g в файле setenv.sh.

Будет ОЧЕНЬ здорово, если мы сможем поднять у себя такие же виртуалки. Скажите, возможно ли будет поднять 25 таких процессов на одной машине i7 3.4GhZ (4 ядра), 16 gb RAM?

Мы поднимали около 20 процессов на более слабых настройках. Сейчас используем 2 ядерный сервер на Digital Ocean для нагрузочных тестов.
Документацию по настройке сервера для нагрузочного тестирования сегодня планируем выложить.

По поводу забивания канала. Вы правы. Если верить atop, в пике у нас было что-то в районе 295 мбит/сек. При этом, хостер нам даёт не жёсткие 100 мбит, т.е. превысить можно (если есть свободный ресурс), но ненамного и ненадолго.

Мы сейчас рассматриваем добавление защиты от переполнения. Т.е. обозначаем порог, например 100 Mbps и на подходе к этому порогу начинаем отклонять коннекты пользователей, например 80 Mbps чтобы избежать переполнения.

Вопрос, откуда могло получиться даже 250 мбит/сек.

Как уже писал выше, WebRTC, если начинаются проблемы с каналом, начинает запрашивать досылку пакетов. Эти запросы и досылки могут генерировать много дополнительного трафика. Скорее всего это произошло после выхода за допустимую полосу.

Либо я сильно ошибся, допустив всего 1.3 мбит на стрим, либо я не знаю.

Битрейт стрима, отправляемого паблишером, не ограничен. Браузер пытается развернуть его по-максимуму, насколько хватает полосы и процессора. При этом чем динамичнее картинка в кадре, тем выше битрейт.
Поэтому, правильнее всего ограничить эти битрейты настройками:

webrtc_cc_min_bitrate=300000
webrtc_cc_max_bitrate=400000

сделав их более предсказуемыми и поддающимися расчету.

Вопрос, корректно ли утверждение, если стример "замьютил" своё видео, его поток, содержащий теперь только звук, будет "занимать" значительно меньше 1 мбита?

По нашим тестам, VP8 снижает до 30 kbps, H.264 снижает почти до нуля.

 

[alexanderY]

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

Отлично, спасибо. Ждем.

Мы сейчас рассматриваем добавление защиты от переполнения. Т.е. обозначаем порог, например 100 Mbps и на подходе к этому порогу начинаем отклонять коннекты пользователей, например 80 Mbps чтобы избежать переполнения.

Да, будет здорово. Сразу пожелания, если возможно:

• в случае, когда порог достигнут и новые коннекты отклоняются - на клиенте должна быть возможность четко это распознать. Что коннекта нет именно по этой причине. Чтобы мы могли дать пользователю понятное объяснение.
  
• наверное, в API стоит добавить информацию о пороге и о том, какой трафик генерируется в данный момент. Чтобы мы могли мониторить эту информацию и реагировать как-то. Добавлять сервера и т.д.

webrtc_cc_min_bitrate=300000
webrtc_cc_max_bitrate=400000

сделав их более предсказуемыми и поддающимися расчету.

Правильно ли я считаю, при максимальном битрейте 400000, трех стримах и 30 зрителях будет генерироваться трафик 400000 * 3 * 30 = 36 мбит/сек примерно?

 

[Max]

Правильно ли я считаю, при максимальном битрейте 400000, трех стримах и 30 зрителях будет генерироваться трафик 400000 * 3 * 30 = 36 мбит/сек примерно?

Да, примерно так и должно быть.

Сразу пожелания, если возможно

Спасибо. Учтём в реализации.