Производительность Freeswitch

Презентация Sangoma Technologies©, на ClueCon 2015, посвященная производительности FreeSWITCH.
Докладчик Moises Silva.
Все это сопровождалось очень интересной речью, полагаю, но в моем распоряжении только слайды, но даже они представляют определенный интерес.

Содержание

  • Производительность (Performance Basics)
  • FreeSWITCH Core Basics
  • Улучшение производительности (Performance Tweaks)
  • Расчет прозводительности (Feature Performance Cost)
  • Заключение

Performance Basics

Тестирование и расчет производительности сложны и сильно подвержены искажениям.

На производительность могут влиять даже минимальные изменения в аппаратном и программном обеспечении.

Процессы при создании SIP соединений в Linux можно разделить на группы в большей степени зависимые от следующих аспектов:

  • CPU-bound - т.е. процессы время выполнения которых зависит в основном от вычислительной мощности процессора.
  • I/O bound - когда время потраченное на завершение задачи зависит главным образом от операций ввода / вывода. (В дальнейшем просто CPU-зависимые и I/O зависимые)
  • Потоки выполнения (threads)
  • Конфликты ресурсов/блокировок.

оригинал

оригинал

Performance testing and measurement is hard to do and very prone to errors

  • Performance can change widely from seemingly minor hardware/software changes
  • This presentation focuses on Linux and SIP call bridging performance CPU-­Bound, I/O Bound, Threads, Resource/Lock Contention
  •   You cannot improve what you don’t measure

FreeSWITCH Core

FS многопоточная система.
  • Большинство потоков I/O зависимые.
  • Но транскодирование, трансрейтинг, генерация тональных сигналов подмешивают в них элементы CPU-зависимости.
  • I/O модель ядра FS является блокирующей, а не асинхронной.
  • Каждое плечо вызова (a-leg, b-leg) имеет собственный сеансовый поток проходящий через конечный автомат и может быть представлен следующей грубой схемой:
    • init -­> routing -­> execute app -­> hangup -­> reporting -­> destroy
  • Мониторинг потоков происходит в их сигнальном стеке (sofia, freetdm).
  • Эти потоки являются долгоиграющими и выполняют такие специфические задачи как: SIP сигнализация за пределы контекста вызова, инициация приглашения (invite) и тп.
  • События подсистемы запускают потоки для событий отправки.
  • Конференции удваивают кол-во потоков на каждое плечо вызова.
  • На каждого участника (конференции) создается 2 потока:
    • Поток сессии (поток обработки состояний вызова и медиа выход).
    • И входящий поток конференции (запускается при подключении к конференции и получает поток медиа сессии).
    • Даже небольшая функция может запускать потоки.
    • Например установленный параметр rtp_timer_name=soft при выполнении Playback() запускает дополнительный поток потребляющий медиа сессии.

оригинальный текст

оригинальный текст

FreeSWITCH is an insanely threaded system (the good kind of insane)

  • Most threads are I/O bound
  • But transcoding, transrating, tone generation introduce CPU-­‐bound elements into the mix
  • FreeSWITCH core I/O model is blocking, not async
  • Every call leg has its own session thread walking through a state machine, roughly, like this:
  • init -­> routing -­> execute app -­> hangup -­> reporting -­> destroy
  • Monitoring threads per signaling stack (e.g sofia, freetdm)
  • These threads are long-­lived and perform very specific tasks (e.g process SIP signaling out of a call context, initial invite etc)
  • Event subsystem launches threads for event dispatch
  • Conferences duplicate your use of threads per call leg. For each participant you have 2 threads:
  • Session thread (handles call state and media output)
  • Input conference thread (launched when joining the conference, reads media from the session)
  • Even small features might launch threads
  • e.g. (Semng) Session timer=soft (Здесь данные были искажены, единственный известный мне таймер в fs, который может иметь иметь значение soft, это rtp_timer_name) when performing a playback() launches an extra thread to consume media from the session

Performance Tweaks

Улучшение производительности.

Logging

  • Журналирование создает дополнительную нагрузку на подсистему.
  • Каждый оператор журнала помещается в очередь, как событие.
  • Каждый оператор журнала доставляется в соответствующий модуль (syslog, file, console)
  • Установите уровень журналирования ядра равным warning в файле switch.conf.xml
  • Не пишите уровень debug на SSD диск. Он умрет очень быстро.
  • Если для вас важно держать уровень журналирования debug, поместите лог в tmpfs assistant и настройте ротацию.

Database

  • Ванильная база данных sqlite должна размещаться в tmpfs во избежания затора ввода / вывода:
    • [ERR] mod_event_socket.c:<> Socket Error [Too many open files]
  • Но при этом вероятен риск потери данных о SIP регистрациях. при внезапной перезагрузке (kernel panic) или отключении питания.
  • Большая часть других данных временная ( channels, sip dialogs и тд).
  • Наилучшим вариантом будет миграция на postgresql , mysql или какую-нибудь другую ODBC совместимую СУБД:
    • Это позволит вам перемещать рабочую нагрузку БД на другой сервер.
    • Улучшится производительность для приложений, которые читают основную информацию (каналы, вызовы и т. д.).
    • Таблицы, такие как каналы, вызовы, задачи, sip_dialogs, не нужно сохранять. Вы можете переместить эти таблицы в память (например, движок MEMORY на MySQL), если вам не нужна устойчивость к падениям.
    • Не забудьте установить auto-create-schemas = false и auto-clear-sql = false, если вы создаёте схему БД самостоятельно (см. switch.conf.xml)
    • Если вы используете MySQL используйте механизм InnoDB для лучшего параллелизма в данных, требующих сохранения (например, регистрация SIP).
      • innodb_flush_log_at_trx_commit = 0
      • sync_binlog = 0

Использование PostgreSql для Core и Internal БД

Freeswitch Core DB в Postgresql

SIP Stack

  • Sofia запускает следующие потоки при использовании sip_profiles:
    • Главный поток профиля (runs Sofia UA stack scheduling)
    • Рабочий поток (проверяет статус sip регистраций)
    • Поток чтения стека (разрешает входящий трафик)
  • Что можно улучшить:
    • Можно распределить трафик между несколькими SIP профилями для улучшения производительности:
freeswitch@fs:~$ fs_cli -x 'sofia status' | grep profile
               office_vip	profile	          sip:mod_sofia@192.168.0.123:5076	RUNNING (17)
                   secure	profile	          sip:mod_sofia@192.168.0.123:5075	RUNNING (43) (TLS)
                   office	profile	          sip:mod_sofia@192.168.0.123:5077	RUNNING (14)
                      rst	profile	          sip:mod_sofia@192.168.0.123:5072	RUNNING (21)
                 external	profile	          sip:mod_sofia@192.168.0.123:5080	RUNNING (110)
                   branch	profile	          sip:mod_sofia@192.168.0.123:5078	RUNNING (57)
                     test	profile	          sip:mod_sofia@192.168.0.123:5079	RUNNING (0)
                peterstar	profile	           sip:mod_sofia@123.123.123.123:5071	RUNNING (3)
                 internal	profile	          sip:mod_sofia@192.168.0.123:5070	RUNNING (57)
9 profiles 0 aliases

Memory Allocation

  • FS pools используют модули которые зависимы от других библиотек или модулей.
  • Для более эффективного использования памяти можно использовать распределители, вроде tcmalloc или jemalloc.
  • Это легко применить при загрузке:
    • LD_PRELOAD=“libtcmalloc.so.x.x.x" ./freeswitch
  • Mysql тоже рекомендуется запускать с одним из этих Memory allocators: tcmalloc или jemalloc

Dialplan

Здесь сказаны простые вещи, которые могут показаться банальными и несущественными, но возможно это и есть самое важное.
  •  Планируйте ваш диалплан таким образом, чтобы в процессе эксплуатации он не превратился в кучу костылей и заплаток.
  • Не включайте функциональность которую вы не используете, все имеет цену.
  • Просто загруженный, но не используемый модуль тратит драгоценные циклы процессора.
  • Общие факторы эффективности, которые следует учитывать (учитывая производительность этих функций):
    • Media relay
    • Tone Detection
    • Recording
    • Transcoding

Использование Lua и БД для обслуживания диалплана

Freeswitch Lua Dialplan

оригинальный текст

оригинальный текст

Logging

  • Logging adds stress to the event subsystem
  • Every log statement is queued as an event
  • Every log statement is delivered to logger modules (syslog, file, console)
  • Set core logging level to warning in switch.conf.xml
  • Do not write debug logs to an SSD in a loaded system. You’ll kill the SSD soon.
  •   If you want to keep debug level, you can put logs into tmpfs and rotate open

Database

  • The native sqlite core database must go to tmpfs to avoid I/O bottlenecks
  • On tmpfs however you risk losing SIP registration data on a power outage or any sudden restart (e.g kernel panic)
  • Most other data is transient (e.g channels, sip dialogs, etc)
  •   Eventually you might need to migrate to postgresql , mysql or some other database via odbc
  • Allows you to move db workload elsewhere
  • Better performance for applications that read the core info (channels, calls, etc)
  • Tables such as channels, calls, tasks, sip_dialogs, do not need to persist. You can move those tables to memory (e.g MEMORY engine on MySQL) if you don’t need fault tolerance
  •   Remember to set auto-­create-schemas=false and auto-clear-sql=false if you create the db schema on your own (see switch.conf.xml)
  • If using MySQL:
    •   Use the InnoDB engine for better concurrency in data that requires persistence (e.g SIP registration)
      • innodb_flush_log_at_trx_commit=0
      •   sync_binlog=0

SIP Stack

  • Sofia launches the following threads per profile:
  • Main profile thread (runs sofia UA stack scheduling)
  • Worker thread (checks expired registrations)
  • Stack listener thread (accepting inbound traffic)
  • You can distribute your traffic among more sofia profiles for improved concurrency

Memory Allocation

  • FreeSWITCH pools Using modules that depend on libraries or modules not using pools can benefit from using an alternative memory allocator
  • Memory tcmalloc and jemalloc are good alternatives
  •   Reports on the mailing list of improvement if using mod_perl
  • Easy to try on your own workload:
    • LD_PRELOAD=“libtcmalloc.so.x.x.x« ./freeswitch
  • Recommended to run mysql with either tcmalloc or jemalloc

Dialplan

  •   Careful planning of your dialplan goes a long way
  • Do not enable functionality you don’t need, everything has a cost
  • Just loading a module might be consuming precious cpu cycles
  • Common performance factors to consider (mind the performance cost of those features):
    • Media relay
    • Tone DetecHon
    •   Recording
    • Transcoding

Measurement Tools

Test Server

  • Linux CentOS 6 (kernel 2.6.x)
  • FreeSWITCH v1.4 git branch
  •   Intel Xeon 64bit processor w/ 8 cores
  •   Intel SSD
  •   16GB of RAM

Test Lab

Test FreeSWITCH Server Switchy Load Generator (FreeSWITCH) Load Generator (FreeSWITCH) ESL ESL SIP SIP

  • 2k@50cps simple audio bridge
  • 2k@50cps tone detecNon
  • 1k@50cps simple audio bridge
  • 1k@50cps session recording
  • 1k@50cps transcoding PCMU/G722
  • 4k@80cps bypass media
  • Dialplan
  •   Use bypass media selecHvely whenever you can
  •   Avoid transcoding, use late-­negotiation and inherit_codec=true

If you must do transcoding, you can offload to a hardware transcoder

Final Thoughts

  • You have to measure your own work load
  • No easy answers with performance, but you have the tools to find what works for you
  • Sangoma Technologies -­‐ © 2015
  • freeswitch/fs_scaling.txt
  • Последние изменения: 2018/10/11