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

Discussion in 'Web Call Server 5' started by alexanderY, Feb 27, 2017.

  1. alexanderY

    alexanderY Member

    Здравствуйте.
    Всё работало несколько дней без сбоев. Вчера у пользователей начались проблемы. Либо дисконнект через полминуты, либо сразу не подключается. На стороне браузера выглядит так:
    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".

    Attached Files:

  2. Max

    Max Administrator Staff Member

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

    alexanderY Member

    Выслал.
  4. alexanderY

    alexanderY Member

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

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

    Max Administrator Staff Member

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

    alexanderY Member

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

    Max Administrator Staff Member

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

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

    alexanderY Member

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

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

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

    Max Administrator Staff Member

    Обычно перезапуск с помощью этой команды помогает:
    Code:
    service webcallserver restart
    Редко бывает что при перезапуске не останавливается процесс.
    Если вдруг после перезапуска что-то не работает, нужно провести его еще раз по шагам с убийством процессов.
    1. Остановить сервер.
    Code:
    service webcallserver stop
    2. Проверить остались ли процессы.
    Code:
    ps aux | grep java
    3. Убить процессы, если остались
    Code:
    kill PID
    где PID - id процесса
    4. Еще раз проверить и убить
    Code:
    kill -9 PID
    5. После этого можно запускать сервер.
    Code:
    service webcallserver start
    На вашем севрере перезапустили и демо работает.
    Есть проблема с самым первым стримом на Play после запуска. С ним разбираемся.
  10. alexanderY

    alexanderY Member

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

    Max Administrator Staff Member

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

    alexanderY Member

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

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

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

    Max Administrator Staff Member

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

    Дисконнект пользователя может быть тоже двух видов:
    1) Нормальный дисконнект. Например если юзер закрыл Chrome-браузер.
    В этом случае браузер успеет отправить закрывающий Websocket-фрейм и сервер сразу получает информацию о том, что юзер Disconnected.
    2) Unexpected дисконнект. Например если реально упало соединение или жестко скрэшился браузер и не успел отправить завершающего фрейма.
    В этом случае работают keep alive, которые настроены в конфиге server.properties
    Code:
    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
    Например если выставить настройки
    Code:
    keep_alive.server_interval =2000 (минимально возможное значение)
    keep_alive.probes          =2
    То повторные попытки можно начинать только через 4 секунды, а лучше через 5.
    Last edited: Feb 28, 2017
  14. alexanderY

    alexanderY Member

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

    alexanderY Member

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

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

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

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

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

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

    Max Administrator Staff Member

    Возможно был забит канал и в результате началсь такие проблемы.
    Какое разрешние видеопотока у вас используется?
    Можно ограничить битрейт для всех в конфиге flashphoner.properties
    Code:
    webrtc_cc_min_bitrate=300000
    webrtc_cc_max_bitrate=400000
    Т.е зажать битрейты в этом интервале.
    Если продолжают отваливаться, то уменьшить настройки еще в 2 раза
    По-умолчанию, WCS не имеет верхних ограничений и паблишеры могут развивать высокие бтрейты, в результате которых зрители могут забить канал или паблишеры начнут конкурировать за канал.
    Это крэш-файлы, которые говорят что ядро скрэшилось.
    Чтобы от них избавиться, рекомендуется использовать следующие настройки:
    1. Устновить JDK 1.8 Oracle HotSpot, как описано здесь
    2. Отключить декодирование потоков в flashphoner.properties
    Code:
    streaming_video_decoder_fast_start=false
    По-умолчанию все потоки декодируются для возмжности быстрой конвертации в другие форматы, снапшотов, и т.д. Отключение этой настройки позволит увеличить производительность и убрать крэши в ваших кейсах.
    У нас есть для этого специальные лоадтесты. Немного позже выложим документацию по их настройке. Суть тестов - мы можем поднять виртуалку Ubuntu без UI и на ней запускать опять же без UI процессы браузера Chrome, который подключается к потокам и тянет видео, потом через указанное в настройках время отключается, тем самым эмулируя работу зрителей.
    Основных проблемы видно две
    1. Отваливаются зрители при "засорени" канала.
    2. Происходит крэш сервера.
    Первую можно попытаться решить уменьшением и фиксацией битрейта.
    Вторую, временным отключением декодинга.
    Мы со своей стороны проведем ряд тестов и посмотрим что можно сделать чтобы улучшить работу сервера.
  17. alexanderY

    alexanderY Member

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

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

    Будет ОЧЕНЬ здорово, если мы сможем поднять у себя такие же виртуалки. Скажите, возможно ли будет поднять 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 мбита?
  18. Max

    Max Administrator Staff Member

    Мы разобрали крэш файлы. Наиболее вероятно случилось следующее.
    На каком-то этапе была превышена ширина серверного канала от хостера 100 Mbps, после чего начали сбрасываться пакеты. Когда сбрасываются пакеты, WCS и браузеры начинают запрашивать их досылку, что еще больше нагружает канал сервера. В результате канал был еще больше перегружен - до значений в 250 Mbps и выше, хостер начал еще больше сбрасывать, и т.д. В результате произошел выход WCS уже по оперативной памяти за heap 3g в файле setenv.sh.
    Мы поднимали около 20 процессов на более слабых настройках. Сейчас используем 2 ядерный сервер на Digital Ocean для нагрузочных тестов.
    Документацию по настройке сервера для нагрузочного тестирования сегодня планируем выложить.
    Мы сейчас рассматриваем добавление защиты от переполнения. Т.е. обозначаем порог, например 100 Mbps и на подходе к этому порогу начинаем отклонять коннекты пользователей, например 80 Mbps чтобы избежать переполнения.
    Как уже писал выше, WebRTC, если начинаются проблемы с каналом, начинает запрашивать досылку пакетов. Эти запросы и досылки могут генерировать много дополнительного трафика. Скорее всего это произошло после выхода за допустимую полосу.
    Битрейт стрима, отправляемого паблишером, не ограничен. Браузер пытается развернуть его по-максимуму, насколько хватает полосы и процессора. При этом чем динамичнее картинка в кадре, тем выше битрейт.
    Поэтому, правильнее всего ограничить эти битрейты настройками:
    Code:
    webrtc_cc_min_bitrate=300000
    webrtc_cc_max_bitrate=400000
    сделав их более предсказуемыми и поддающимися расчету.
    По нашим тестам, VP8 снижает до 30 kbps, H.264 снижает почти до нуля.
  19. alexanderY

    alexanderY Member

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

    Да, будет здорово. Сразу пожелания, если возможно:
    • в случае, когда порог достигнут и новые коннекты отклоняются - на клиенте должна быть возможность четко это распознать. Что коннекта нет именно по этой причине. Чтобы мы могли дать пользователю понятное объяснение.
    • наверное, в API стоит добавить информацию о пороге и о том, какой трафик генерируется в данный момент. Чтобы мы могли мониторить эту информацию и реагировать как-то. Добавлять сервера и т.д.
    Правильно ли я считаю, при максимальном битрейте 400000, трех стримах и 30 зрителях будет генерироваться трафик 400000 * 3 * 30 = 36 мбит/сек примерно?
  20. Max

    Max Administrator Staff Member

    Да, примерно так и должно быть.
    Спасибо. Учтём в реализации.

Share This Page