Обстакановка следующая... Провел синтетические тесты прогой SIPP 3.5.1 телефонную станцию Asteriks 13 на предмет максимального количества установленных SIP соединений. Без RTP эхо. Требовалось выяснить какое кол-во соединений сможет обрабаьываться Получилось вот что: № IP PBX OS Мак. Кол-во соединений Примечание 1 Asterisk 13 Debian 8.7 Kernel 3.16 200 При достижении лимита система доступна, падает сервис. Требуется рестарт виртуальной машины. Самостоятельно не восстанавливается. 2 Asterisk 13 Ubuntu 14.04 Kernel 4.4 170 При достижении лимита система доступна, падает сервис. Потом сервис восстанавливается самостоятельно 3 Asterisk 13 Ubuntu 16.10 Kernel 4.8 200 При достижении лимита система доступна, падает сервис. Требуется рестарт виртуальной машины. Самостоятельно не восстанавливается. 4 Asterisk 13 CentOS 6.8 Kernel 2.6.32 от 35 до 140 При достижении лимита система доступна, сервис не стабилен. Способен обрабатывать звонки, но при повторных тестах макс. кол-во соед. каждый раз разное 5 Asterisk 13 CentOS 7 Kernel 3.10 5000 Работает стабильно. Все по дефолту. SIP-драйвер chan_sip. Вопросы следующие: 1. почему получился такой разброс по кол-ву соединений между дебианоподобным ОС и Центосом 7? С Центосом 6 понятно.Древнее ядро и тд и тп. 2. как использовать модуль chan_pjsip? Вроде бы запущен, но как использовать не понятно
Я думаю, тут вопрос в ядре. Изначально, Цент всё таки серверная операционная система и ядро там соответствующее. Более правильным было бы мерять кол-во соединений не на Астериск, а на сервер как таковой. И уже потом на Астериск. Там играет роль как обрабатываются соединения на уровне ядра. Я когда свои сервера пилил, исходил именно из этого, поэтому изначально ставил Цент. Про chan_pjsip ничего не скажу - не занимался им. Но как я понимаю, это альтернативный драйвер вместо chan_sip. Т.е. его надо загружать не вместе, а вместо chan_sip.
вообщем нашел косяк, который никак не исправляется. в Дебиане 8 и Ебунте 16 Астериск не может сделать больше 200 соединения или открыть 400 сокетов. Общее системное ограничение при крэше было - 508 открытых сокетов. Использовал команды netstat -anp | grep ast | wc -l netstat -anp | wc -l Хотя вывод команда ulimit -n показывает 4096 ранее установленное руками. В центосе 7 ulimit выводит 1024 сокетов, но тем не менее 2500 соединений или 5000 UDP коннектов без проблем организует. Где копать?
1. sysctl, net.core.somaxconn : по-умолчанию вроде 128, но это очередь, поставь 1000. 2. /etc/security/limits.conf : у пользователя, рута и системы могут отличаться свои ulimit'ы , перепроверь - под каким ползователем запускается сервис? и какие у того юзверя лимиты. пропиши увеличенное значение open files лучше в /etc/security/limits.conf , чем руками, перезапусти сервис.
вообщем чтобы снять ограничение для Астериска на Дебиане\Ебуньте на максимальное кол-во открытых сокетов пришлось раскоментить строку и установить свое значение в файле /etc/asterisk/asterisk.conf maxfiles=65536 В Центосе ничего раскоментивать не надо. По итогу Астериск на Дебиане держал одновременно SIP сессий цельный 1200 штук и постоянно обновлялся. Суточный тест показал стабильность и съело всего лишь 500 мегабайт ОЗУ из 2 гектар. Загрузка ЦПУ около 2-3 %. В качестве сигнального роутера более чем 1 ядра для виртуалке и 2 гектары Рамы. В реальности нагрузка на виртуалку будет значительно меньше
из нормального только freeswitch, но чтение xml файлов то еще изъебство. можно создавать свои конечно же, но чтение конфигов Астера проще и нагляднее. Нагрузочная способность канального драйвера chan-sip у Астера и sofia у Фрисвича в принципе одинаковая. Для корпоративной телефонии более чем достаточно. К тому же Астеру по дефолту прикручивается канальный драйвер pjsip, который устойчивее и занимает меньше кода и процессорного времени в сравнении с chan-sip. C учетом современных объемов памяти и мощностей цпу абсолютно эквипенисуально использоваеть Астер или Фрисвич. Для операторской телефонии применяются совсем другие решения и это не опенсорс.
Очередной астер. Я не верю в опенсорс как в ПО для продакшена. Отправлено с моего SM-N910C через Tapatalk
Я тоже не верю, но как технологический костыль опенсорс ПО можно заюзать. к примеру, сигнальный SIP агрегатор для УПАТС, коих штук так несколько сотен. Или в качестве SBC, чтобы объединить IP сетки, между которыми нет маршрутизации. А вот всякие изъебства в виде ДВО - это уже удел вендоров и тяжелого суппорта за бабло
