Комментарии 13
Может быть причина в том, что собственный стек SIP они (разработчики Asterisk) забросили. Работает несколько инсталляций на 18 версии с PJSIP, бэкенд на PostgreSQL 13, утечек по памяти не наблюдаю.
сориентируйте по количеству пиров на единицу астериска
~600 пиров
System uptime: 9 weeks, 5 hours, 36 minutes, 37 seconds
total used free shared buff/cache available
Mem: 5.8Gi 577Mi 149Mi 149Mi 5.1Gi 4.8Giпопробуйте увеличит количество пиров до 5000 +/-, картина поменяется кардинально.
Утечки должны быть при любом количестве пиров, у меня 600 на 9 недель аптайма. У вас при 5000 за сутки утекает.
Утечки должны быть при любом количестве пиров
Простите, на основании чего Вы пришли к такому выводу?
У вас при 5000 за сутки утекает.
Почему за сутки? Месяц +/-. Световой день в посте в кавычках - аллегория.
В том смысле, что если утечки есть (ошибки в коде), то они будут вне зависимости от количества пиров. Маловероятно, что бы race condition увеличивал объем утечки. 5000 у нас точно не будет, абонентов разделяем по географическому признаку. Звонки гоняем между узлами.
В том смысле, что если утечки есть (ошибки в коде), то они будут вне зависимости от количества пиров. Маловероятно, что бы race condition увеличивал объем утечки.
А вот не факт, помимо состояния гонки есть куча узких мест, тот же накопительный эффект по буферам.
5000 у нас точно не будет
Вот в этом то и вся соль
Это не отменяет того факта, что однажды chan_sip перейдет в состояние поддержки dropped
Это не отменяет того факта, что однажды chan_sip перейдет в состояние поддержки dropped
Как и факт того, что PJSIP не решает проблемы массового Realtime. Переводить окружение из примера в статье на pjsip, что бы поиметь все те же проблемы, ну такое себе занятие.
Вы же понимаете, что были, есть и будут legacy-площадки где pjsip не то что-бы не нужен, он там просто не дает ни какого профита, как минимум.
А еще если пир у вас сойдет с ума и начнет слать REGISTER с большой скоростью тоже начнет течь. Может если у вас больше 100 пиров поставить перед всем этим kamailio и заодно получить возможность зарезервировать этот asterisk?
У нас такая схема работает на очень большом количестве пиров и asterisk на которые распределяется через dispatcher.
воспринималась и реализовывалась как дополнение к решению на основе выноса регистраций на внешний сервер.
Это как раз и есть решение с registrar server и именно на kamailio. А решение с кэшем - это попытка понять, как победить realtime и много пиров без registrar server и возможно ли такое в принципе
если вам нужен просто registrar middlebox, то можно посмотреть в сторону opensips с его модулем mid_registrar, он работает из коробки. В камаилио такой функционал придеться писать самому.
А вообще, вы правильно написали, делать систему где на астериске >5K регистраций и потом это чинить, затея так себе.
Что не так с Asterisk Realtime и как с этим жить