Причины перегрузки звездочки
После движущейся Звездочки от одного сервера до другого я заметил, что 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%, у меня нет подсказки, почему Звездочка была ошибочна.
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 для ПЕРЕГРУЗКИ.
О чем перегрузка и chanuavail параметры? Что еще может влиять на него? Как отличить перегрузку моей собственной Звездочки и "ответов перегрузки", отправленных 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 core и выше.
Помните, вы запускаете сценарий a2billing для каждого вызова. Сделать убедитесь, что ваши настройки php.ini предоставляют достаточно памяти и ресурсов для времени выполнения сценария, иначе вы получите ошибки.
Не забудьте установить MAXFILES, SYSMAXFILES и PRIORITY в safe_asterisk - если вы этого не сделаете, могут возникнуть аналогичные проблемы.
Если вы используете систему с высоким энергопотреблением, установите PRIORITY на -10. Так и будет дать процессу Asterisk высокий приоритет в доступе к ЦП и ресурсам распределение.
Удачи.