Настройка параметров Asterisk для высокой нагрузки

Мы подошли к критически важному этапу. До этого момента мы работали преимущественно с графическим интерфейсом FreePBX и логикой диалплана. Однако при масштабировании системы до уровня корпоративной АТС с сотнями одновременных вызовов ресурсов «из коробки» становится недостаточно.

Когда нагрузка на сервер растет, администраторы часто совершают ошибку: просто добавляют оперативную память или ядра CPU. Но Asterisk — это сложный механизм. Его производительность зависит от взаимодействия с ядром Linux и распределения внутренних задач. Сегодня мы научимся проводить тонкий тюнинг системы, выходя за рамки GUI.

Что такое высокая нагрузка для Asterisk

В VoIP высокая нагрузка — это не количество телефонов на столах, а интенсивность процессов:

1. CPS (Calls Per Second) — сколько новых звонков поступает в секунду. Это нагрузка на сигнализацию и парсинг пакетов.
2. Concurrent Calls — количество одновременных активных разговоров. Это нагрузка на медиа-потоки (RTP), транскодинг и сеть.

Для стабильности в таких условиях нужна оптимизация потоков. Asterisk использует многопоточную архитектуру. Если не настроить «исполнителей» (threads) внутри процессора, возникнет очередь. Результат: задержки звука («робоголос») или игнорирование входящих пакетов.

Глобальный тюнинг через asterisk.conf

Файл asterisk.conf — фундамент системы. FreePBX редко вносит сюда изменения, поэтому файл редактируют вручную.

Настройте ключевые параметры в секции [options]:

[options]
; Использование внутреннего тайминга для генерации тонов и конференций
internal_timing = yes

; Запуск Asterisk с высоким приоритетом в планировщике Linux
highpriority = yes

; Максимальное количество одновременных вызовов
maxcalls = 500

; Лимит Load Average, при котором Asterisk перестанет принимать новые звонки
maxload = 4.0

; Отключение детального логирования в консоль (экономит CPU)
verbose = 0
debug = 0

Параметр internal_timing критичен для чистоты звука в очередях и IVR. Он позволяет Asterisk генерировать тайминги программно, не полагаясь на внешние аппаратные таймеры. ⏱️

Оптимизация потоков в PJSIP

Главная сила PJSIP — Threadpool (пул потоков). В отличие от старого chan_sip, PJSIP распределяет обработку пакетов между множеством потоков.

Если пул настроен неверно, система «захлебнется» при массовой перерегистрации телефонов (например, после сбоя сети в офисе). Как показано на Схеме 1, правильно настроенный пул обрабатывает запросы параллельно, не блокируя ядро системы.

Для настройки пула во FreePBX используйте файл pjsip_custom.conf:

[global]
type=global
; Начальное количество потоков в пуле
threadpool_initial_size=20
; Максимальное количество потоков
threadpool_max_size=100
; Время жизни простаивающего потока (в секундах)
threadpool_idle_timeout=60

Системные лимиты и дескрипторы файлов

Asterisk — это процесс в Linux. По умолчанию ОС разрешает одному процессу открывать не более 1024 файлов. В VoIP каждый звонок занимает минимум два сетевых сокета (файловых дескриптора). Если лимит исчерпан, Asterisk не примет вызов и не сможет записать лог.

Рассчитайте лимит по формуле: $L = (C \times 3) + 512$ Где $L$ — лимит дескрипторов, а $C$ — количество одновременных вызовов.

Отредактируйте /etc/security/limits.conf:

# Установка лимита открытых файлов для пользователя asterisk
asterisk soft nofile 65536
asterisk hard nofile 65536

Важно: После изменения лимитов выполните systemctl restart asterisk. Команда core reload в консоли Asterisk здесь не поможет. 🛠️

Чек-лист оптимизатора

Проверьте систему по трем пунктам:

• Удалите лишнее: В modules.conf выгрузите неиспользуемые протоколы и кодеки.
• Убавьте логи: На «боевом» сервере держите verbose на минимуме.
• Исключите транскодинг: Старайтесь использовать один кодек на всей сети (например, только G.711). Перекодирование аудио — самый тяжелый процесс для процессора.

Мы подготовили сервер к серьезным нагрузкам. Но любая настройка asterisk.conf бессмысленна, если вы не видите результатов в цифрах.

В следующей теме мы перейдем к инструментам мониторинга. Вы научитесь находить «узкие места» и понимать, что серверу плохо, еще до того, как пользователи начнут жаловаться на качество связи.