Пользователь bandys написал сразу во многих профильных чатах Телеграм:
Приветствую други. Что имеем: Asterisk 1.8 на Centos7. DAHDI собран 2.11.1 Realtime MySQL CDR тудаже пишется. ODBC. Через AMI originate инициализируется звонок сторонеей программой на произвольный номер.
В случае ответа абонента второй конец кидается в очередь. Инициируется 7 звоноков на одного свободного оператора.Операторов от 50.
Если операторов становится больше 70, астериск тупо перестает звонить. В логах ничего подозрительного кроме того, что при попытки вызова транк отвечает unavaleble. В этот момент подключиться к серверу не возможно софтфоном. Любые загруженные модули перегружаются без проблем, но безрезультатно. Помогает только перезапуск астериска. Все по SIP.
Очередь rrmemmory. Настройки все минимальные. В системе увеличен параметр максимального количество открытых файлов и всего остального. Диски ssd, xeon, 64Gb памяти. В htop, atop... нагрузки везде не большие. Транки с несколькими провайдерами уже, балансируются звонки примерно поровну.
Кодеки ulaw alaw g729.
В момент проблемы нельзя посмотреть core show channels. Говорят на прошлой инсталяции centos 6.1 asterisk 1.6 до 110 операторов сидели легко. Но он канул в лету. Всё. Больше уж не знаю что смотреть. Есть у кого то какие мысли по этому поводу? Куда ещё покапать? Инициация звонков через AMI происходит не равномерно. Бывают всплески, но с проблемой не увидел корреляции. Помогите кто чем может :)
ТТХ сервера в таком виде:
Ivan Poddubny откоментировал предыдущие сообщения:
Никакая супер-архитектура не исправит багу древней версии Астериска с дедлоком на доступе к списку каналов.
У админов и программистов есть склонность к тому, чтобы делать "умные" навороченные решения там, где достаточно простых и дешёвых. И в плане железа тоже. Нафига Астериску 64 гига памяти, например?
Или вместо сайта на php+mysql воротят кубернетис кластер, микросервисы, шину, nosql - архитектура же, масштабируемость.
1500 одновременных вызовов один Астериск легко переваривает, на машине с 4 гб. Там совсем не память узкое место. Xeon(R) CPU E5-2620 v3. ~1300 звонков - CPU на ~60% нагружен
с cdr
и ещё mysql на той же машине
без транскодирования и записи
это транзитный. но на pbx-ах нагрузка ниже - например, на одном 400 одновременных, 1500 очередей, 1000 sip-учёток, 2000 мобильных. Там процессор попроще, всё равно нагрузка тоже выше 30% не поднимается.
без транскодинга, конечно. всё в alaw.
bandys:
По моему кейсу. Манипуляции найденые на issues не помогли. Поднятие до 11 версии астериска, так же не дали положительного результата. Теперь имеем вот такую ошибку https://issues.asterisk.org/jira/plugins/servlet/mobile#issue/ASTERISK-26956 На данный момент убран диалплан из базы. Мониторим эффект. Дальше будем пробовать опускать ОС до 6.9. Может у кого то появятся ещё идеи? Exceptionally long voice выскакивает не так часто как на 1.8, но всё же пару раз в день бывает. Хотя нагрузка на выходных не большая.
...
Продолжу свой репортаж. Сегодня был запущен asterisk 1.6 на centos 6. Целый день под нагрузкой 90 операторов отработало всё без проблем. Ночью буду поднимать на 6 центос 11 астериск. Посмотрим как себя поведёт. Видимо что то в ядре 3 не так. Понять бы что
...
bandys, [13.02.19 01:17]
[В ответ на bandys]
Доброй ночи. Продолжение. На centos6 и asterisk 1.6 всё работает стабильно. 1.8 и 11 падают. Заметил, что на 1.8 и выше транскодинг показывает 17000 почти на всех кодеках. На 1.6 порядка 3000 мксек. 1.6 держит больше 100 операторов. Версии выше фризятся при выше 50 операторов. Осталось одно отличие проверить. На 11 стоит MySQL 5.7(исторический приехал с centos7), а на 1.6 стоит 5.1 Завтра попробую
Ivan Poddubny, [13.02.19 01:25]
> Заметил, что на 1.8 и выше транскодинг показывает 17000 почти на всех кодеках. На 1.6 порядка 3000 мксек.
1.6 честно считает миллисекунды, а в более новых версиях эти значения больше не отражают реальную задержку при транскодинге.
bandys, [13.02.19 01:47]
[В ответ на Ivan Poddubny]
Понятно. Спасибо за инфу. 1.6 суд по всему во многом честнее :)
SilverJoe SPA, [13.02.19 07:07]
[В ответ на bandys]
Ты на 6 центоси собирал 1.6, 1.8 и 11?
До 13 и 16 версии не добрался?
bandys, [13.02.19 07:14]
Да, всё собирал конечно. 13 и 16 не подходят. Там AMI поменяли, а у них на нем есть не мало. Да и что то думаю не сильно бы помогло
bandys, [13.02.19 07:15]
У свича вроде 1.6 в девайсах как раз
SilverJoe SPA, [13.02.19 07:17]
[В ответ на bandys]
1.4
SilverJoe SPA, [13.02.19 07:18]
[В ответ на bandys]
А мне любопытно сравнить. Да еще на пжсипе
SilverJoe SPA, [13.02.19 07:18]
[В ответ на bandys]
Так проблема в астере или ОС?
bandys, [13.02.19 07:19]
Тут надо под нагрузку запустить второй сервак, потом думать о переделках. Попробую. Тоже мысль про пыжысип посещает
bandys, [13.02.19 07:19]
Выходит в астере
bandys, [13.02.19 07:20]
Хотя 1.6 на 7 не пробовал
SilverJoe SPA, [13.02.19 07:20]
1.6 астер на 7 центоси бы тогда собрать и проверить
SilverJoe SPA, [13.02.19 07:07]
[В ответ на bandys]
Ты на 6 центоси собирал 1.6, 1.8 и 11?
До 13 и 16 версии не добрался?
bandys, [13.02.19 07:14]
Да, всё собирал конечно. 13 и 16 не подходят. Там AMI поменяли, а у них на нем есть не мало. Да и что то думаю не сильно бы помогло
bandys, [13.02.19 07:15]
У свича вроде 1.6 в девайсах как раз
SilverJoe SPA, [13.02.19 07:17]
[В ответ на bandys]
1.4
SilverJoe SPA, [13.02.19 07:18]
[В ответ на bandys]
А мне любопытно сравнить. Да еще на пжсипе
SilverJoe SPA, [13.02.19 07:18]
[В ответ на bandys]
Так проблема в астере или ОС?
bandys, [13.02.19 07:19]
Тут надо под нагрузку запустить второй сервак, потом думать о переделках. Попробую. Тоже мысль про пыжысип посещает
bandys, [13.02.19 07:19]
Выходит в астере
bandys, [13.02.19 07:20]
Хотя 1.6 на 7 не пробовал
SilverJoe SPA, [13.02.19 07:20]
1.6 астер на 7 центоси бы тогда собрать и проверить
SilverJoe SPA, [13.02.19 07:21]
[В ответ на bandys]
А ты как ставил:
Дахди был?
Таймерфд какой?
bandys, [13.02.19 07:22]
Дахди везде последний из 2 ветки. Дахди тулсы так же
SilverJoe SPA, [13.02.19 07:24]
[В ответ на bandys]
timerfd или как его в астерах любопытно какой использовался
bandys, [13.02.19 07:25]
Таймер с дахди же приезжает
SilverJoe SPA, [13.02.19 07:25]
[В ответ на bandys]
Волбще, справедливости ради, надо было это все тестировать вынеся мускул отдельно
SilverJoe SPA, [13.02.19 07:26]
[В ответ на bandys]
Да но не факт что астер использует именно его
bandys, [13.02.19 07:28]
Там есть в asterisk.conf internal_timing yes
bandys, [13.02.19 07:29]
Пробовал играться
SilverJoe SPA, [13.02.19 07:29]
[В ответ на bandys]
module show like timer
bandys, [13.02.19 07:30]
Смотрел. Дахдишный
SilverJoe SPA, [13.02.19 07:32]
[В ответ на bandys]
На всех версиях астера которые ты проверял стоял таймер дахди? Правильно?
SilverJoe SPA, [13.02.19 07:33]
А на проде, который на 7 центе?
bandys, [13.02.19 07:43]
[В ответ на SilverJoe SPA]
Да
bandys, [13.02.19 07:44]
[В ответ на SilverJoe SPA]
Когда там 1.8 стоял, точно дахдишный. На 11 не смотрел
SilverJoe SPA, [13.02.19 08:35]
[В ответ на bandys]
Мысль мелькнула - а нельзя оставить 1.6 транзитным с ами в сторону интеграции а для оригинаций, обработки медиа развернуть 13 или 16?
bandys, [13.02.19 08:37]
[В ответ на SilverJoe SPA]
Разделение обзвона и операторов предполагается в дальнейшем. Я ещё хочу перевести инициацию звонка из ami в call файл. Можно одним файлом запускать кучу звонков а не оригинейтить каждый
SilverJoe SPA, [13.02.19 08:41]
[В ответ на bandys]
Один коллфайл - один оригинейт
А дальше зависит от бизенс-процесса
Возможно можно 7 звонков на оператора засунуть в один диал.
Хз, надо разбираться
bandys, [13.02.19 08:50]
Говорят по ami есть ограничение 3000 запросов. Может в этом дело. Правда не нашёл официальной инфы о таком ограничении
ros tel, [13.02.19 08:54]
[В ответ на bandys]
попробуйте колфайлы подсунуть когда уперлись
если проканает, значит точно AMI
SilverJoe SPA, [13.02.19 08:56]
[В ответ на bandys]
Это не ами а таскпроцессор. А хотя может в таскпроцессоре для ами
bandys, [13.02.19 08:57]
там не на моей стороне инициация звонка. там всё сложно и не быстро
Марк Егоров, [13.02.19 08:59]
[В ответ на bandys]
Не запросов, а длинна очереди. То есть, как я понимаю, если их, запросы, влупить вообще по хардкору, то они не будут успевать обрабатываться - и будут становиться в очередь. Вот у нее 3к.
bandys, [13.02.19 08:59]
возможно. есть где почитать про это?
SilverJoe SPA, [13.02.19 09:00]
[В ответ на bandys]
Да я знаю как это делается. Проводил не раз
И разрабов уговаривал с ами перейти на ари оригинейт
Он хоть более гибок
Не помню как в ами но в ари можно кучу переменных передать
И если диалплан верный - одной командой (ари) все семь вызовов запустить на оператора
bandys, [13.02.19 09:00]
смущает, что если это та самая очередь, то почему на 1.6 всё норм
Марк Егоров, [13.02.19 09:00]
[В ответ на bandys]
Но это таск процессинг. У тебя пока его нет.
Марк Егоров, [13.02.19 09:01]
[В ответ на bandys]
Собери с дебагом.
ros tel, [13.02.19 09:02]
[В ответ на bandys]
а оригинация случайно не в синхронном режиме?
bandys, [13.02.19 09:04]
[В ответ на Марк Егоров]
Смотрел таск. Там глубины выше 30 не видел
SilverJoe SPA, [13.02.19 09:04]
[В ответ на ros tel]
+1 за вопрос!
про Async: True я и забыл спросить для АМИ
bandys, [13.02.19 09:06]
вроде да ast_manager->originate(
ros tel, [13.02.19 09:07]
ётиц оно ище и на пыхе чтоль?
bandys, [13.02.19 09:07]
видимо. трока от разраба
ros tel, [13.02.19 09:09]
поряться в этом классе убедиться что выставится Async: True
можно дамп трафика снять и там поковырять
SilverJoe SPA, [13.02.19 09:09]
[В ответ на ros tel]
а какая разница. это ж внешняя система
ros tel, [13.02.19 09:09]
[В ответ на SilverJoe SPA]
у меня отзвон в такси на подобном говне работал
вставало в ступор по неизвестным причинам в любое неудобное время
SilverJoe SPA, [13.02.19 09:10]
[В ответ на ros tel]
хз. от разарба пхп зависит
у Свича вообще весь дилаплан через аги в пхп и работают его железочки и хорошо
ros tel, [13.02.19 09:11]
зависало именно на стороне пыхи
не мной было писано
выкинул к чертям, переделав на go
Ivan Poddubny, [13.02.19 09:11]
[В ответ на bandys]
очевидно, что дедлок на доступе к списку каналов, связанный с app_queue, появился в 1.8, присутствует в 11, но вы же ни один лог и ни один конфиг не показали, поэтому гадать можно долго и смысла в этом мало. Смотреть на AMI и call-файлы и прочие частности - это подход "ищу потерянные ключи под фонарём, потому что там светло".
подождем развязки....
