a
param name="sql-buffer-len" - еще увелчил до 8М
а помогло с cps?
просто у меня при cps 1 примерно лагало
Size: a a a
2020 December 29
RK
a
Roman Kokorev
а помогло с cps?
просто у меня при cps 1 примерно лагало
просто у меня при cps 1 примерно лагало
мне помогло с утечкой памяти это, и проблем cps
a
у меня была проблема что при cps скажем даже 100 он мог часть вызовов бить плюс память утекать
a
два сервака я увел на постгрю увеличили дескрипторы до 200 и буфер до 8 - проблема ушла
a
одну перевел на оперативную память, с теми же настройками, проблема тоже ушла
a
ну я еще понимашеь для cps лавинной держу min-idle-cpu
RK
благодарю, учту при настройке)
a
по умолчанию он 25%
a
а еще надо собраться с силой и написать им тикет, что можно бы в постгрю при большиз cps фигачить multiple insert а то получается легкое дрочево базы, или хотя бы memcache хотя сделали
I
Roman Kokorev
Приветствую.
Подскажите, у кого-нибудь получалось выжать больше 700 звонков с проксированием RTP без деградации звука?
Сам проверку осуществлял по такой схеме
sipp <—-> FS <—-> sipp
в sipp multi_port не заработал даже на последней версии, может в этом проблема, а может в чем-то ещё.
Сервер FS железка, по спеку жирная, недогружена, ДП наипростейший, CPS не влияет.
Рекомендации с confluence по настройки сервиса и ОС выполнены.
Подскажите, у кого-нибудь получалось выжать больше 700 звонков с проксированием RTP без деградации звука?
Сам проверку осуществлял по такой схеме
sipp <—-> FS <—-> sipp
в sipp multi_port не заработал даже на последней версии, может в этом проблема, а может в чем-то ещё.
Сервер FS железка, по спеку жирная, недогружена, ДП наипростейший, CPS не влияет.
Рекомендации с confluence по настройки сервиса и ОС выполнены.
до 5-6к прокачивали, статический дп, всё кроме mod_sofia отключали и внутреннюю базу отключали, приложений никаких не выполнялось кроме bridgе двух каналов. Где-то после 5.5к RTP с задержками поднимался даже с небольшим CPS(10-20), но артефактов не было и по сигналке тоже тормозов не было, LA на сервере при этом не прям адовый был, поэтому упирались уже в потолок возможностей фрисвича
по железяке был какой то двухпроцессорный сервер на голдах, или 48 или 64 ядра, но FS был 1.6 еще
по железяке был какой то двухпроцессорный сервер на голдах, или 48 или 64 ядра, но FS был 1.6 еще
a
до 5-6к прокачивали, статический дп, всё кроме mod_sofia отключали и внутреннюю базу отключали, приложений никаких не выполнялось кроме bridgе двух каналов. Где-то после 5.5к RTP с задержками поднимался даже с небольшим CPS(10-20), но артефактов не было и по сигналке тоже тормозов не было, LA на сервере при этом не прям адовый был, поэтому упирались уже в потолок возможностей фрисвича
по железяке был какой то двухпроцессорный сервер на голдах, или 48 или 64 ядра, но FS был 1.6 еще
по железяке был какой то двухпроцессорный сервер на голдах, или 48 или 64 ядра, но FS был 1.6 еще
вы базу рубили
I
как вариант отрубить попробовать и посмотреть что будет
I
ну или пощупать более ранние версии FS
a
полностью солидарен с вами
a
если она не нужна то можно
a
а если failover уже ни как
RK
по бд оставил как есть, только в рам
<param name="core-db-name" value="/usr/local/freeswitch/ramdisk/core.db" />
RDBMS не использовал
<param name="core-db-name" value="/usr/local/freeswitch/ramdisk/core.db" />
RDBMS не использовал
I
вы базу рубили
разница кстати не в разы была, не вспомню точно, если не ошибаюсь по количеству процентов на 20-30 +/- приросло в сравнении с sqlite + tmpfs, но и CPS там небольшой был