Биллинг медленно работает

{toc:maxLevel=2}

h1. Как понять почему биллинг работает медленно?
Проверьте биллинг по следующему алгоритму:
# Разработчики *CarbonSoft* постоянно оптимизируют работу биллинга, повышая его призводительность. [Обновите биллинг на свежую версию|Обновление биллинга].
# Возможно, причина медленной работы в проблеме внутри БД. Попробуйте сделать [резервное коприрование БД с последующим восстановлением|CarbonBilling:Восстановление БД биллинга из резервной копии.#Создание резервной копии БД с последующим восстановлением].
# Проверьте соответсвует ли сервер биллинга [системным требованиям|Системные требования#Carbon Billing 5].
# Проверьте, возможно, причиной замедления является одна из проблем описанных в разделе "[Частые причины медленной работы биллинга|Биллинг медленно работает#Частые причины медленной работы биллинга]".
# Если вы не пользуетесь Userside, [отключите фоновую выгрузку|Настройки (в файле)#Настройка демона фоновых задач].
# Включите многопоточность ядра биллинга по [статье|Worker (ядро биллинга)#Многопоточность].
# В свежих версиях биллинга добавлена возможность работы БД под упралением Firebird 5. Провеьте какая версия СУБД Firebird используется.
{code}
sqlexec -l "show version" | grep Version
{code}
{code}
ISQL Version: LI-V2.5.9.27156 Firebird 2.5
{code}
Если используется Firebird 2, и в биллинге более 5000 абонентов перейдите на Firebird 5. Для этого создайте заявку на [портале|https://helpdesk.carbonsoft.ru/login.php].
# Проверьте скорость работы ядра биллинга, и при необходимости [настройте ядро|Worker (ядро биллинга)#Многопоточность#Тонкая настройка многопоточности] для оптимальной производительности.
# Если не получилось найти причину самостоятельно, создайте заявку на [портале|https://helpdesk.carbonsoft.ru/login.php].

h1. Частые причины медленной работы биллинга

Ниже описаны возможные причины с которыми сталкивались инженеры *CarbonSoft* и методы решения

{info}
В любом случае нестандартного поведения сервера полезно проверять системный лог
{code}
tail -f /var/log/messages
{code}
{info}

h2. Перегрев процессора

{code:title=Пример записи в логе /var/log/messages корневой системы}
* CPU3: Package temperature above threshold, cpu clock throttled
{code}

Такая запись в логе говорит о том, что система приостанавливает процессор из-за перегрева. Проверьте температуру процессора с помощью утилиты sensors (устанавливается с помощью команды *yum install lm_sensors*)

h2. Другие проблемы аппаратного обеспечения

{code:title=Пример записи в логе /var/log/messages корневой системы}
* [Hardware Error]: Machine check events logged
{code}

Запись говорит об аппаратной проблеме, выявленной при самодиагностике ОС. Например, это исправленная ошибка в памяти с исправлением ошибок (ECC). В большинстве случаев не является причиной замедления работы, однако в случае повторения чаще чем раз в пару месяцев необходима расширенная диагностика памяти.

h2. Проблемы дисковой подсистемы

Если в top/atop длительно присутствуют процессы в состоянии D (непрерываемый сон), то в большинстве случаев это следствие недостатка производительности дисковой подсистемы.
Запускаем в момент проблемы:

{code}
iostat -dmx 2
{code}

либо

{code}
iostat -dmx 2 /dev/sda /dev/sdb
{code}

где 2 - интервал повторения в сек, /dev/sdX - интересующие нас диски (без них покажет все)

Нужно обратить внимание на соотношение столбцов rMB/s и/или wMB/s с %util. Если %util больше 90 при скорости менее 10 мегабайт/сек (в любую сторону), то налицо деградация скорости жесткого диска.
Скорость может деградировать по разным причинам:
* отказ диска в массиве: если это аппаратный RAID, то необходимо уточнить в /var/log/dmesg тип контроллера и установить соответствующее ПО для взаимодействия с ним, запросить через него состояние дисков;
* несоответствие типа массива задаче: например, под систему оптимальнее использовать RAID10, нежели RAID6, т.к. у последнего медленная скорость записи;
* диск медленный сам по себе, например энергосберегающие модели со скоростью 5400 RPM, скорость должна быть 7200 RPM.

h2. Биллинг перегружен обработкой трафика (слишком часто отправляется аккаунтинг)


h3. Диагностика

Создание абонента или проведение денежных средств занимает достаточно много времени - более минуты. В процессе диагностики проблемы следует изучить лог обработчика абонентов. Если в нем видно, что много времени уходит на обработку account_traf и количество постоянно большое (около 1000 или больше), можно попробовать изменить частоту отправки Accountg-Update чтобы снизить нагрузку на обработчик данных по трафику.

Посмотреть количество и скорость обработки объёмов трафика:
{code}[root@billing ~]# egrep 'finished:daemons.account_traf' /app/asr_billing/var/log/worker.log | tail -n 3
2018-10-09 09:20:05,989 - worker - worker - INFO - Fork has finished:daemons.account_traf.0, Processed 945 in 89.275s.
2018-10-09 09:21:36,117 - worker - worker - INFO - Fork has finished:daemons.account_traf.0, Processed 969 in 89.218s.
2018-10-09 09:23:06,914 - worker - worker - INFO - Fork has finished:daemons.account_traf.0, Processed 978 in 90.484s.{code}
Посмотреть сколько еще записей не обработаны:
{code}[root@billing ~]# sqlexec /var/db/buff_traf.gdb "select count(*) from traffic where status=0 or status is null"

COUNT
============
4528613 {code}

h3. Решение

# Нужно снизить частоту отправки Acocunting-Update (в примере - два часа или более) на биллинг и убедиться что данные по трафику не дублируются, отправляясь одновременно в Netflow и Radius-Accounting.
# Увеличить таймаут Radius-сессий на биллинге, по истечении которого, если не поступал аккаунтинг, сессия считается оборвавшейся. Значение должно более чем в два раза превышать Acct-Interim-Interval.
# Сбросить все сессии на всех NAS (вероятно можно перезагрузить роутеры) чтобы они установились заново
# Либо дождаться пока обработается уже собранная информация по объемам трафика, либо взять БД трафика из скелета без этой информации (однако в таком случае не обработанная информация по объёмам трафика будет утеряна). Как взять базу из скелета описано в статье "[Восстановление БД биллинга из резервной копии|CarbonBilling:Восстановление БД биллинга из резервной копии.]"


Ниже приведен скрипт, который выполнит первые два пункта
{code}#!/bin/bash

#Значение Acct-Interim-Interval
attr_value=8600
#Время жизни сессии для биллинга, равное удвоенному Acct-Interim-Interval плюс 15 минут
const_value=$((900 + $attr_value * 2))

#Устанавливается таймаут accounting update
curl "http://169.254.80.82:8082/rest_api/v2/VpnConst/" -d 'method1=objects.get&arg1={"const_id":43}&method2=objects.set&arg2={"const_value":"'$const_value'"}&method3=save&arg3={}'

#Получает список NAS с ID RADIUS-атрибутов Acct-Interim-Interval если они есть, sed для фильтрации пустых строк вывода sqlexec
sqlexec "set heading off; select
n.id,
coalesce(nrp.id,'none')
from
nas n
left join
Nas_Radius_Params nrp on n.id=nrp.nas_id and lower(attribute)='acct-interim-interval'
where
n.id>=1000
and n.id in (select distinct nas_id from users where auth_type in (0,6) and nas_id>=1000)" | sed '/^$/d' |\

while read nas param; do

echo 'nas='$nas 'param='$param
#Отключение опции "Использовать radius вместо NetFlow" в настройках NAS
curl "http://169.254.80.82:8082/rest_api/v2/Nas/" -d 'method1=objects.get&arg1={"id":'$nas'}&method2=objects.set&arg2={"radius_ins_netflow":0}&method3=save&arg3={}'

#Если нет атрибута Acct-Interim-Interval, то он создаётся, если есть - устанавливается значение "частота 8600, при любом статусе баланса и блокировки"
if [[ $param == 'none' ]]; then
curl "http://169.254.80.82:8082/rest_api/v2/NasRadiusParams/" -d 'method1=objects.create&arg1={"attribute":"Acct-Interim-Interval","thevalue":"'$attr_value'","balance_status_id":0,"block_status_id":0,"op":":=","nas_id":"'$nas'","is_hotspot_attrib":0}'
else
curl "http://169.254.80.82:8082/rest_api/v2/NasRadiusParams/" -d 'method1=objects.get&arg1={"id":'$param'}&method2=set&arg2={"thevalue":"'$attr_value'","balance_status_id":0,"block_status_id":0}&method3=save&arg3={}'
fi

done{code}
Атрибуты добавятся только на те NAS к которым привязаны учетные записи с типом авторизации "по vpn pppoe/pptp" и "любая через RADIUS", чтобы добавить на всех маршрутизаторах, уберите условие "*and n.id in (select distinct nas_id from users where auth_type in (0,6) and nas_id>=1000)*"

h2. Биллинг перегружен обработкой трафика (слишком много "первых пакетов")

Если замедление так же связано с обработкой трафика, включите уровень логирования *INFO*, если в логе [nf_collector|CarbonBilling:Collector] много записей *first_packet=0* и они часто повторяются по одним и тем же адресам, значит проблема в этом.

h2. Абоненты долго обрабатываются

h3. Ситуация

Вы создали нового абонента, Вас перевело в его карточку и над номером договора долго не пропадает сообщение что абонент в обработке:

!subscriber_in_progress.png|border=1,width=400!

Это говорит о том, что [итерация Воркера|Worker (ядро биллинга)] длится слишком долго и он не справляется с работой. В первую очередь нужно убедиться, что скорость работы дисков достаточная (в первую очередь диск на котором находится БД), как это диагностировать подробно описано в статье "[CarbonBilling:Проблемы с оборудованием]", явным признаком проблемы скорости работы является долгое выполнение запросов, при том что тот или иной воркер не произвел ни какой работы:
{code}2018-12-28 13:50:27,259 - worker - worker - INFO - Fork has finished:daemons.nas_stats.0, Processed 0 in 500.677s.{code}
В приведенном примере воркер обновляющий статистику NAS (количество подключенных абонентов и т.д. на соответствующей вкладке настроек оборудования) не выполнил каких-либо операций, но работал в течение 500 секунд, что говорит о том что запросы к БД медленно выполняются.

h3. Решение

Проверьте, что БД не слишком большого размера - если она превышает 10Гб, это уже достаточно много, система мониторинга создаст автоматическую заявку по этой проблеме [ALARM Превышен лимит размера БД|Система мониторинга#check_billing_db_size.sh]. 10Гб достаточно чтобы хранить данные 20000 абонентов без дополнительных оптимизаций или активной работы механизма партиционирования. Если эти значения превышены, то нужно найти причины роста объёма БД. Далее очистить лишние данные и уменьшить размер БД. Ниже описано, как это сделать.
Если уменьшение размера БД не дало результатов, возможно нашим разработчикам удасться оптимизировать запросы по выборке данных - создайте заявку на [портале|https://helpdesk.carbonsoft.ru/login.php].

h3. Решение

# Определите, какие таблицы БД занимают больше всего места:
Скрипт покажет топ 3 таблиц, отсортированных по количеству "страниц". В большинстве случаев такая сортировка достаточно точно поможет определить, на что ушло место. Скрипт для *Firebird 5*.
{code}
chroot /app/asr_billing/ gstat-fb5 169.254.30.50:/var/db/billing.fdb -u SYSDBA -pass servicem -data | \
grep -E '^[A-Z]|Data pages:' | grep -v 'Gstat' | sed ':a;N;$!ba;s/\n */ /g; s/,//g' | \
awk '{print $5,"data pages;",$1";","average fill",$8}' | \
sort -h | tail -n 3
{code}
# Проанализируйте вывод, будет что-то вроде этого:
{code}
39178 data pages; ARCH_ACCOUNT_STACK; average fill 87%
75789 data pages; RADIUS_SESSIONS; average fill 86%
949991 data pages; EVENTS_STACK; average fill 94%
{code}
*949991 data pages* - количество страниц данных занятое таблицой. *average fill 94%* - коэфицент заполнения страниц данных.
По выводу видно что под таблицау EVENTS_STACK в базе отведенено существенно больше места, чем под все прочие.
# Дальнейшие шаги зависят от конкретных таблиц - суть в том, чтобы TOP3 были примерно одного порядка)
# Решив проблему переполнения таблиц, сделайте [резервную копию и восстановление из неё|Восстановление БД биллинга из резервной копии.#Создание резервной копии БД с последующим восстановлением] - таким образом работает механизм "сборки мусора". После операции должен увеличится коэфициент *average fill*, при нормальной работе БД он будет более 80%.

h4. EVENTS_STACK

В общих чертах описание возможных проблем переполнения стека команд для оборудования можно найти в статье по [системе мониторинга|Система мониторинга#check_events_stack_count.sh].

Описание подсистемы отправки команд и пути отладки описаны в [статье|nas_event_daemon]

Проблема чаще всего возникает, если используется авторизация по RADIUS.

Наиболее частые причины:
* Медленный диск, в результате чего при перезагрузке оборудования происходит массовая авторизация абонентов, но события не отправляются достаточно быстро, поэтому абоненты продолжают авторизоваться и стек продолжает пополняться
* Проблемы оборудования: возможно, что-то не так с NAS-сервером, в результате чего постоянно отпадают RADIUS-сессии и абоненты переавторизуются, стек копится, например NAS-сервер слишком медленно отвечает биллингу
* Ошибки в [скрипте управления NAS|Интеграция оборудования интернет#Управление сессиями абонентов на оборудовании]: команды отправляются с ошибкой, а в скрипте событий описана обработка этих ошибок, но не слишком оптимально, это так же может замедлять отправку событий и приводить к "снежному кому" в стеке

Возможно Ваша причина тут не описана - здесь помогут хорошее понимание схемы взаимодействия биллинга с оборудованием, анализ логов и знание особенностей используемого оборудования.

h4. ARCH_ACCOUNT_STACK

В таблице хранятся проводки, влияющие на баланс абонента. "Проводки" в терминах бухгалтерии.

Возможные причины и решения:
# У Вас включена опция [сохранять движения всего трафика| Глобальные настройки биллинга и оператора#Глобальные настройки оператора] в настройках оператора связи, чтобы предоставлять подневную (или почасовую) детализацию объёмов трафика абонентам.
Решить можно следующими способами:
#* Уменьшите частоту отправки данных по трафику. В статье о [службах сбора статистики|Описание работы служб сбора статистики] Вы найдёте информацию по настраиваемым параметрам частоты отправки - уменьшите частоту в 5-10 раз.
#* Настройте [период хранения исторических данных в базе|Настройка периода хранения исторических данных в базе]. Так [детализация расхода|Детализация расхода] станет доступна за менее длительный период, но база будет работать быстрее
# Возможно, это проводки за списания и тогда через [конструктор отчётов|CarbonBilling:Конструктор отчетов] постарайтесь понять структуру расхода: у каких абонентов больше всего проводок, по каким операциям и тд. Возможно, где-то в настройках услуг или ведении абонентов допущена ошибка.

h4. RADIUS_SESSIONS

В таблице хранится история RADIUS-авторизаций. Если таблица слишком разрослась, настройте [период хранения исторических данных в базе|Настройка периода хранения исторических данных в базе] - уменьшите его. Если это не помогло - возможно, проблема так же где-то в авторизациях или оборудованиии и, вероятно, помимо таблицы с историей авторизаций, у Вас так же разрастётся EVENTS_STACK.

h2. Медленно работает веб-интерфейс администратора

В биллинг добавлен инструмент, способный отследить долго выполняющиеся запросы к веб-серверу, а также косвенно судить о их наличии в прошлом. Это утилита диагностики uwsgitop.
Использование утилиты:

{code}
chroot /app/asr_billing uwsgitop /tmp/uwsgi_stats.socket
{code}

Если в поле STATUS много строчек с busy — значит, администраторский интерфейс действительно загружен.
Если при этом поле AVG показывает более 2-х секунд, то нужно отследить, что именно тормозит - время работы есть в логе web-сервера:

{code}
tail -f /var/log/admin_web_server.log | perl -ne 'print "$1\t$_" if (m/generated \d+ bytes in (\d+) msecs/ and $1>500)'
{code}

Чаще всего там будут неоптимизированные отчеты

Если нет явных причин медленной работы, то это повод проверить системные требования.

h2. Очень долго загружается веб-интерфейс администратора, много запросов на служебные порты биллинга

Возможно биллинг перегружен сетевыми запросами. Посмотрите сообщения ядра ОС командой *dmesg*, возможно там есть сообщения о сетевом флуде:

{code}[root@mynetcity_ru ~]# dmesg | grep 'flooding'
possible SYN flooding on port 440. Sending cookies.
possible SYN flooding on port 440. Sending cookies.
possible SYN flooding on port 440. Sending cookies.{code}

Подробная статья по проблеме [есть в документации Red Hat|https://access.redhat.com/solutions/30453]: изнеё можно узнать, что это за ошибка и чем она может быть вызвана.

Основная задача разобраться в источнике трафика.

Порт 440 по-умолчанию используется [для страницы переадресации неавторизованных абонентов|CarbonBilling:Редактирование страниц переадресации абонентов].

Если в Вашей сети нормально, что таких абонентов может быть много, оптимальным решением будет отключить редирект на оборудовании, чтобы не перегражать биллинг.

В общем случае, это нетипично, и необходимо провести диагностику интеграции биллинга и оборудования. Для этого нужно понимать как работают, [схемы интеграции в целом|CarbonBilling:Интеграция оборудования интернет], [служба отправки команд на оборудование|CarbonBilling:nas_event_daemon] и если используется RADIUS, то как [как устроена авторизация по RADIUS через биллинг и как её диагностировать|CarbonBilling:Авторизация по RADIUS].

h3. Решение

# В первую очередь, отключите редиректы, которые вызывают проблему (это могут быть и другие порты, например 445 (авторизация HotSpot) или 442 (отрицательный баланс))
# Когда проблема с доступом будет решена, проанализируйте логи одного или нескольких абонентов, чтобы понять что произошло и почему абонентов не оказалось в списке авторизованных или заблокированных.