Worker (ядро биллинга)

Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.

Изменения (17)

просмотр истории страницы
...
h1. Многопоточность

В ядре реализована функция многопоточности, чтобы равномерно распределять нагрузку по ядрам процессора:
* *abonent_block* \- обрабатывает блокировки абонентов
* *usluga_abon_pay* \- списание абонентской платы и обработка статусов услуг
* *tarif_change* \- переключает тарифы
* *balance_change* \- обновляет состояния балансов
* *status_daemon* \- статусы абонентов
* *send_commands* \- обработка кеша: кеш абонентов, обработка флага modified в БД абонентов (что может говорить службе воркер о необходимости отправки команд на оборудование) , [сброс RADIUS-сессий по таймауту|CarbonBilling:Глобальные настройки биллинга и оператора]
* *pay_cards* \- обрабатывает пополнение баланса через карты оплаты
* *events* \- добавляет в стек команды для отправки на оборудование
* *csv_loading* \- обрабатывает загрузку платежей из csv
* *account_traf* \- регистрирует информацию по объёмам интернет-трафика
* *account_voip* \- обрабатывает зарегистрированный VoIP трафик
* *nas_stats* \- статистика NAS
В ядре реализована функция многопоточности, чтобы равномерно распределять нагрузку по ядрам процессора. Подпроцессы равноверно разпределяются по потокам CPU. Суммарно, все запущенные подпроцессы относятся в одной итерации, пока они не завершили работу новая итерация не начнётся. Таким образом, если запустить слишком много подпроцессов это может не ускорить, а замедлить работу. Скорость работы напрямую зависит от количества потоков процессора, его мощности, а так же количества ОЗУ. Подробнее узнать о конфигурации сервера можно в [статье|Системные требования].

{code}
2018-07-02 12:07:22,778 - worker - worker - INFO - Fork daemons.abonent_block.0:9477
2018-07-02 12:07:22,782 - worker - worker - INFO - Fork daemons.usluga_abon_pay.0:9479
2018-07-02 12:07:22,786 - worker - worker - INFO - Fork daemons.tarif_change.0:9482
2018-07-02 12:07:22,790 - worker - worker - INFO - Fork daemons.balance_change.0:9483
2018-07-02 12:07:22,795 - worker - worker - INFO - Fork daemons.balance_change.1:9485
2018-07-02 12:07:22,823 - worker - worker - INFO - Fork daemons.status_daemon.0:9499
2018-07-02 12:07:22,827 - worker - worker - INFO - Fork daemons.send_commands.0:9503
2018-07-02 12:07:22,832 - worker - worker - INFO - Fork daemons.pay_cards.0:9509
2018-07-02 12:07:22,836 - worker - worker - INFO - Fork daemons.events.0:9517
2018-07-02 12:07:22,841 - worker - worker - INFO - Fork daemons.csv_loading.0:9521
2018-07-02 12:07:22,846 - worker - worker - INFO - Fork daemons.account_traf.0:9526
2018-07-02 12:07:22,850 - worker - worker - INFO - Fork daemons.account_voip.0:9529
2018-07-02 12:07:22,854 - worker - worker - INFO - Fork daemons.nas_stats.0:9532
{code}

Подпроцессы равноверно разпределяются по потокам CPU. Суммарно, все запущенные подпроцессы относятся в одной итерации, пока они не завершили работу новая итерация не начнётся. Таким образом, если запустить слишком много подпроцессов это может не ускорить, а замедлить работу. Скорость работы напрямую зависит от количества потоков процессора, его мощности, а так же количества ОЗУ. Подробнее узнать о конфигурации сервера можно в [статье|Системные требования].
По логу работы сервиса можно увидеть количество данных обработанных за итерацию данных и суммарное время итерации:
{code}
...
2018-07-02 13:13:00,383 - worker - worker - INFO - Processed in one iteration 7265 in 135.563s.
{code}
Один из подпроцессов balance_change обработал 717 операций за 112 секунд, ошибок в работе не произошло. Суммарное время итерации чуть менее 136 секунд. Всего обработано 7265 записей.
Суммарное время итерации чуть менее 136 секунд.

Описиние процессов:
* *abonent_block* - обработка блокировок абонента
* *usluga_abon_pay* \- списание абонентской платы и обработка статусов услуг
* *tarif_change* \- переключает тарифы
* *balance_change* \- обновляет состояния балансов
* *status_daemon* \- статусы абонентов
* *send_commands* \- обработка кеша: кеш абонентов, обработка флага modified в БД абонентов (что может говорить службе воркер о необходимости отправки команд на оборудование) , [сброс RADIUS-сессий по таймауту|CarbonBilling:Глобальные настройки биллинга и оператора]
* *pay_cards* \- обрабатывает пополнение баланса через карты оплаты
* *events* \- добавляет в стек команды для отправки на оборудование
* *csv_loading* \- обрабатывает загрузку платежей из csv
* *account_traf* \- регистрирует информацию по объёмам интернет-трафика
* *account_voip* \- обрабатывает зарегистрированный VoIP трафик
* *nas_stats* \- статистика NAS

h2. Включение и настройка

...
Обычно для ускорения работы ядра биллинг достаточно включить мнгопоточность и добавить несколько потоков обработки баланса. При этом количесво абонентов обрабатываемых за каждую итерацию можно оставить стандартным. Увеличим количество потоков процесса обработки балансов *balance_change*. В конфигурационном файле *asr_billing* установим параметры для balance_change:
{code}
worker['balance_change.fork.cnt']='5' - количество потоков обработки баланса
worker['balance_change.fork.cnt']='5'
{code}

Используя различные значения переменной можно отладить скорость для отладки скорости работы службы воркер.
Пример лога:
{code}
{code:title=Пример лога}
2018-06-27 19:37:29,522 - worker - worker - INFO - Fork has finished:daemons.balance_change.0, Processed 0 in 0.159s.
2018-06-27 19:37:29,523 - worker - worker - INFO - Fork exitcode: 0
...
* При массовых [списаниях|Методы списания] (раз в месяц при типе списания "Ежемесячно" и каждый день при "Ежедневно равными долями в день" или "Ежедневно"), каждый процесс balance_change должен обработать не менее 1000 записей, при этом уложиться в 180 секунд;
* Общее количество потоков службы воркер не должно превышать количество потоков процессора, иначе это может замедлить работу всю системы;
* Мы рекомендыем оставлять запас ядер процессора для выполния других задачь на биллинга;
* Мы рекомендуем оставлять запас ядер процессора для выполнения других задач биллинга;
* На слабых платформах лучше не изменять настройки, а оставить стандартные: 110 абонентов в 1 потоке;
* В системе есть ограничение в *5000* записей на поток вне зависимости от настройек. настроек;
* В количесветве потоков стоит указывать простые числа - 2,3,5,7,11 и так далее;
* При расчёте количесва поток стоит учитывать только процессы, которые реально обрабатывают данные. Например, если вы не используете [карты оплаты|Карты оплаты], то поток их обработки *pay_cards* можно не учитывать в общем количестве потоков.

h3. Особенности настройки:
h5. account_voip

В процессее обработки звонков *account_voip* возможно настроить только количество потоков *account_voip.fork.cnt*. Каждый поток будет обрабатывать *1000* звонков.

h1. Отладка

...