Ниже описаны возможные причины с которыми сталкивалась техподдержка и методы решения
{info} В любом случае нестандартного поведения сервера полезно проверять системный лог
{code}
tail -f /var/log/messages
{code}
{info}
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=objects.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. Решение
Подключите для БД [отдельный диск |CarbonBilling:Добавление диска под БД] с высокой скоростью доступа.
{info} В любом случае нестандартного поведения сервера полезно проверять системный лог
{code}
tail -f /var/log/messages
{code}
{info}
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=objects.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. Решение
Подключите для БД [отдельный диск |CarbonBilling:Добавление диска под БД] с высокой скоростью доступа.