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

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

{toc:maxLevel=2}

{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

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. Решение