После обновления SMG1016M до версии 3.8.0.2088

[Fluke]

Доброго времени суток.

Буквально в прошедшую субботу обновил SMG до версии 3.8.0.2088 и заметил следующее:
Загрузка CPU стала "скакать". Во вложении я прислал скрин.
До обновления ПО таких скачков небыло. TOP показывает что это из-за процесса /usr/lib/erlang/erts-5.9.2/bin/beam -- -root /usr/lib/erlang -progname erl -- -home / -- -config /usr/bin/smg/smg_pa_sip/releases/smg
Существует ли проблема с оптимизацией эрланга в версии 3.8.0.2088?


Ещё я заметил что больше всех выедает ОЗУ процесс /usr/bin/smg/mgapp. За что отвечает этот процесс? Что будет если его прибить?

[Bokrenok]

Доброго времени суток.

Буквально в прошедшую субботу обновил SMG до версии 3.8.0.2088 и заметил следующее:
Загрузка CPU стала "скакать". Во вложении я прислал скрин.
До обновления ПО таких скачков небыло. TOP показывает что это из-за процесса /usr/lib/erlang/erts-5.9.2/bin/beam -- -root /usr/lib/erlang -progname erl -- -home / -- -config /usr/bin/smg/smg_pa_sip/releases/smg
Существует ли проблема с оптимизацией эрланга в версии 3.8.0.2088?

с оптимизацией эрланга проблемы точно нет, он сам по себе такой же как и на предыдущих версиях.
но этот процесс в целом занят обработкой всевозможных SIP-сообщений, может на SMG идёт неравномерная нагрузка по SIP, что приводит к таким всплескам?

Ещё я заметил что больше всех выедает ОЗУ процесс /usr/bin/smg/mgapp. За что отвечает этот процесс? Что будет если его прибить?

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

п.с. анализировать состояние ПО на утечки имеет смысл, когда выскакивает аварийное сообщение "оперативная память заканчивается"

[Fluke]

Доброго времени суток.

Буквально в прошедшую субботу обновил SMG до версии 3.8.0.2088 и заметил следующее:
Загрузка CPU стала "скакать". Во вложении я прислал скрин.
До обновления ПО таких скачков небыло. TOP показывает что это из-за процесса /usr/lib/erlang/erts-5.9.2/bin/beam -- -root /usr/lib/erlang -progname erl -- -home / -- -config /usr/bin/smg/smg_pa_sip/releases/smg
Существует ли проблема с оптимизацией эрланга в версии 3.8.0.2088?

с оптимизацией эрланга проблемы точно нет, он сам по себе такой же как и на предыдущих версиях.
но этот процесс в целом занят обработкой всевозможных SIP-сообщений, может на SMG идёт неравномерная нагрузка по SIP, что приводит к таким всплескам?

Ещё я заметил что больше всех выедает ОЗУ процесс /usr/bin/smg/mgapp. За что отвечает этот процесс? Что будет если его прибить?

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

п.с. анализировать состояние ПО на утечки имеет смысл, когда выскакивает аварийное сообщение "оперативная память заканчивается"

Зато появляются сообщения о высокой загрузке процессора. Такого небыло до обновления!

[Женя]

Можете снять tcpdump, например минут 5 и посмотреть нет ли ничего подозрительного в SIP сообщениях? может брутфорс или дос/ддос?

[Fluke]

Можете снять tcpdump, например минут 5 и посмотреть нет ли ничего подозрительного в SIP сообщениях? может брутфорс или дос/ддос?

За 5 минут там будет столько данных, что едва ли там можно будет разобрать что-то подозрительное. Вообще, порт SIP у нас нестандартный и врятли кто попало ломится к нам. Fail2Ban банит некорректные действия.

[Женя]

тогда пришлите файл конфигурации,
и все же дамп с порта для SIP снимите тоже

[Fluke]

тогда пришлите файл конфигурации,
и все же дамп с порта для SIP снимите тоже

Выслал на почту

[alesx]

Есть ли продвижения по диагностике/решению данного вопроса? Т.к. наблюдаем аналогичную картину.

[Bokrenok]

Есть ли продвижения по диагностике/решению данного вопроса? Т.к. наблюдаем аналогичную картину.

аналогичную в чем?
"график загрузки CPU" аналогичным образом показывает пики загрузки?

[alesx]

С версии 3.8.0.2088
По top тот же процесс забирает более 80% CPU.
Замечали, что нагрузка может и не спадать, а оставаться на уровне 100% (kill -9 не совсем хорошее решение для снятия такой нагрузки)

При необходимости могу приготовить дамп SIP трафика.
И какие данные лучше собрать/предоставить?

[panfilov_ms]

Присоединяюсь к проблеме.
ПО V.3.8.0.2066

[Fluke]

Присоединяюсь к проблеме.
ПО V.3.8.0.2066

Причина была найдена. Дело в том, что в момент обновления устройства, скопилась большая очередь на регистрацию от клиентов. Естественно что пока устройство обновляется клиенты шлют регистрацию но не получают ответа. И вот когда устройство обновилось, началась обработка регистраций всех желающих клиентов. Среднее время запроса регистрации 120 секунд. Это видно по графику. Таким образом каждые 120 секунд обрабатывается большой шквал запросов на регистрацию.

Выход:
В настройках SIP я выставил минимально разрешённое время регистрации в 600 секунд, после чего клиенты принудительно регистрируются каждые 600 секунд. График выровнялся, и такие скачки теперь только каждые 10 минут.

[Fluke]

Есть ли продвижения по диагностике/решению данного вопроса? Т.к. наблюдаем аналогичную картину.

См. мой пост выше

[panfilov_ms]

Присоединяюсь к проблеме.
ПО V.3.8.0.2066

Причина была найдена. Дело в том, что в момент обновления устройства, скопилась большая очередь на регистрацию от клиентов. Естественно что пока устройство обновляется клиенты шлют регистрацию но не получают ответа. И вот когда устройство обновилось, началась обработка регистраций всех желающих клиентов. Среднее время запроса регистрации 120 секунд. Это видно по графику. Таким образом каждые 120 секунд обрабатывается большой шквал запросов на регистрацию.

Выход:
В настройках SIP я выставил минимально разрешённое время регистрации в 600 секунд, после чего клиенты принудительно регистрируются каждые 600 секунд. График выровнялся, и такие скачки теперь только каждые 10 минут.

а если у меня нету сип-абонентов?

[Fluke]

Присоединяюсь к проблеме.
ПО V.3.8.0.2066

Причина была найдена. Дело в том, что в момент обновления устройства, скопилась большая очередь на регистрацию от клиентов. Естественно что пока устройство обновляется клиенты шлют регистрацию но не получают ответа. И вот когда устройство обновилось, началась обработка регистраций всех желающих клиентов. Среднее время запроса регистрации 120 секунд. Это видно по графику. Таким образом каждые 120 секунд обрабатывается большой шквал запросов на регистрацию.

Выход:
В настройках SIP я выставил минимально разрешённое время регистрации в 600 секунд, после чего клиенты принудительно регистрируются каждые 600 секунд. График выровнялся, и такие скачки теперь только каждые 10 минут.

а если у меня нету сип-абонентов?

Вас может ддосят. Основная нагрузка из-за частых RADIUS запросов.