После переноса Asterisk с одного сервера на другой я заметил, что ASR упал на 15-20%. Также я заметил следующее предупреждение в файле журналов
[Dec 8 15:52:00] WARNING[4771][C-00000031] pbx.c: Maximum loadavg limit of 0.900000 load exceeded by 'SIP/889-00000061' (currently 1.010000)!
[Dec 8 15:52:00] WARNING[4771][C-00000031] chan_sip.c: Failed to start PBX (call limit reached)
maxload
был установлен на 2 и позже прокомментирован. Реальная загрузка процессора была ниже 50%, я понятия не имею, почему ошиблась Asterisk.
mysql> SELECT
-> terminatecauseid,
-> count(terminatecauseid),
-> count(terminatecauseid) * 100 / t.cnt
-> FROM cc_call c
-> cross join ( select count(1) as cnt FROM cc_call n where n.starttime BETWEEN '' AND '') t
-> where c.starttime BETWEEN '' AND ''
-> group by c.terminatecauseid;
+------------------+-------------------------+----------------------------------------+
| terminatecauseid | count(terminatecauseid) | count(terminatecauseid) * 100 / t.cnt |
+------------------+-------------------------+----------------------------------------+
| 0 | 16731 | 3.1444 |
| 1 | 184780 | 34.7277 |
| 2 | 21788 | 4.0948 |
| 3 | 51831 | 9.7411 |
| 4 | 165769 | 31.1547 |
| 5 | 40409 | 7.5945 |
| 6 | 50775 | 9.5427 |
+------------------+-------------------------+----------------------------------------+
Удаление maxload
помогло, однако я все еще вижу, что заторы выше нормы. Насколько я понимаю, 6 означает CHANUNAVAIL, а 5 - ЗАГРУЗКУ.
О чем говорят параметры заторов и шануавейлов? Что еще может на это повлиять? Как отличить перегрузку моего собственного Asterisk от «ответов о перегрузке», отправленных софтсвитчами donwstream?
Чтобы диагностировать вашу проблему, вам нужно будет запустить трассировку "tcpdump" в течение дня или что-то в этом роде. Другой вариант - использовать такой инструмент, как voipmonitor (voipmonitor.org) или homer (sipcapture.org).
Сообщения о перегрузке могут быть вызваны различными кодами результата SIP. Обычно перегрузка указывает на то, что вы израсходовали все свои выделенные каналы на удаленном конце. CHANUNAVAIL обычно указывает, что произошел сбой сети или ресурса, и ресурс канала, который вы хотите использовать, недоступен для вашего использования.
Расчет ASR очень глобален, вам нужно точно указать расчет ASR в соответствии с конкретным префиксом назначения. Например, какой у вас ASR для префикса 44 или префикса 33. Таким образом, вы сможете точно указать точную причину падения ASR. Я также предлагаю проверить вашу ACD (среднюю продолжительность разговора), если ваша ACD увеличилась, возможно, вы страдаете от нехватки ресурсов, что является хорошей проблемой, а это означает, что ваш бизнес идет хорошо.
Разложив обсуждение того, как рассчитать ASR и ACD, судя по вашей таблице, вы используете механизм A2Billing. Теперь вам нужно обратить внимание на следующее:
Максимальная нагрузка должна соответствовать типу вашей машины. Например, если вы используете сервер с четырехъядерным процессором, максимальная загрузка 3 хорошо вам подойдет. Обычно я бы установил (CORE COUNT - 1) для Quad / Hex Cores и (CORE COUNT - 2) для любого ядра Octa и выше.
Помните, что вы запускаете сценарий a2billing для каждого звонка. Убедитесь, что в настройках php.ini достаточно памяти и ресурсов для выполнения сценария, иначе вы получите ошибки.
Не забудьте установить MAXFILES, SYSMAXFILES и PRIORITY в safe_asterisk - в противном случае могут возникнуть аналогичные проблемы.
Если вы используете систему высокой мощности, установите ПРИОРИТЕТ на -10. Это даст процессу Asterisk высокий приоритет при доступе к процессору и распределению ресурсов.
Удачи.