|
Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.
|
Изменения (22)
просмотр истории страницы... |
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={}' 'method1=objects.get&arg1={"id":'$param'}&method2=set&arg2={"thevalue":"'$attr_value'","balance_status_id":0,"block_status_id":0}&method3=save&arg3={}' |
fi |
... |
Подключите для БД [отдельный диск |CarbonBilling:Добавление диска под БД] с высокой скоростью доступа. |
h2. Всё очень медленно работает, не проходят платежи, не управляется оборудование, не работают авторизации |
h3. Причина |
Проверьте, что БД не слишком большого размера - если она приевышает 10Гб, это уже достаточно много, система мониторинга создаст автоматическую заявку по этой проблеме [ALARM Превышен лимит размера БД|https://docs.carbonsoft.ru/51019784#Системамониторинга-checkbillingdbsize.sh] |
|
В среднем, 10Гб достаточно чтобы хранить данные нескольких десятков тысяч абонентов без дополнительных оптимизаций или активной работы механизма партиционирования. |
|
Если абонентов у Вам меньше 50 000, при этом база вышла за рамки 10Гб, нужно изучить, на что ушло место, очистить лишние данные и уменьшить размер БД. Ниже описано, как это сделать. |
h3. Решение |
# Определите, какие таблицы БД занимают больше всего места: |
{code}chroot /app/asr_billing/ gstat-fb /var/db/billing.gdb -data | \ grep -E '^[A-Z]|Data pages:' | sed ':a;N;$!ba;s/\n */ /g; s/,//g' | \ awk '{print $5,"data pages;",$1,$2";",$9,"data page slots;",$12,"average fill"}' | \ sort -h | tail -n 3{code} |
Скрипт покажет топ 3 таблиц, отсортированных по количеству "страниц". В большинстве случаев такая сортировка достаточно точно поможет определить, на что ушло место. |
# Проанализируйте вывод, будет что-то вроде этого: {code} |
... |
949991 data pages; EVENTS_STACK (193); 949991 data page slots; 94% average fill{code} По выводу видно что под таблицау EVENTS_STACK в базе отведенено существенно больше места, чем под все прочие. |
# Дальшеньшие Дальнейшие шаги зависят от конкретных таблиц - суть в том, чтобы TOP3 были примерно одного порядка) |
# Решив проблему переполнения таблиц, сделайте резервную копию и восстановление из неё - таким образом работает механизм "сборки мусора". Это описано в статье по системе мониторинга в [тесте размера БД|https://docs.carbonsoft.ru/pages/viewpage.action?pageId=51019784#Системамониторинга-checkbillingdbsize.sh] |
h4. EVENTS_STACK |
В общих чертах описание возможных проблем переполнения стека команд для оборудования можно найти в статье по [системе мониторинга|https://docs.carbonsoft.ru/pages/viewpage.action?pageId=51019784#Системамониторинга-checkeventsstackcount.sh]. |
|
Описание подсистемы отправки команд и пути отладки описаны в статье [https://docs.carbonsoft.ru/display/CarbonBilling/nas_event_daemon|nas_event_daemon] |
|
Проблема чаще всего возникает, если используется авторизация по RADIUS. |
|
Наиболее частчые причины: |
* Медленный диск, в результате чего при перезагрузке оборудования происходит массовая авторизация абонентов, но события не отправляются достаточно быстро, поэтому абоненты продолжают авторизоваться и стект продолжает пополняться |
* Проблемы оборудования: возможно, что-то не так с NAS-сервером, в результате чего постоянно отпадают RADIUS-сессии и абоненты переавторизуются, стек копится, например NAS-сервер слишком медленно отвечает биллингу |
* Ошибки в [скрипте управления NAS|https://docs.carbonsoft.ru/pages/viewpage.action?pageId=51708724#Интеграцияоборудованияинтернет-Управлениесессиямиабонентовнаоборудовании]: команды отправляются с ошибкой, а в скрипте событий описана обработка этих ошибок, но не слишком оптимально, это так же может замедлять отправку событий и приводить к "снежному кому" в стеке |
Возможно Ваша причина тут не описана - здесь помогут хорошее понимание схемы взаимодействия биллинга с оборудованием, анализ логов и знание особенностей используемого оборудования. |
h4. ARCH_ACCOUNT_STACK |
... |
Возможные причины и решения: |
# У Вас включена опция [сохранять движения всего трафика|https://docs.carbonsoft.ru/pages/viewpage.action?pageId=63242421#Глобальныенастройкибиллингаиоператора-Глобальныенастройкиоператора] в настройках оператора связи, чтобы предоставлять подневную (или почасовую) детализацию объёмов трафика абонентам. |
Решить можно следующими способами: |
#* Уменьшите частоту отправки данных по трафику. В статье о [службах сбора статистики|https://docs.carbonsoft.ru/pages/viewpage.action?pageId=126484488] Вы найдёте информацию по настраиваемым параметрам частоты отправки - уменьшите частоту в 5-10 раз. |
#* Настройте [период хранения исторических данных в базе|https://docs.carbonsoft.ru/pages/viewpage.action?pageId=107577360]. Так [детализация расхода|https://docs.carbonsoft.ru/pages/viewpage.action?pageId=50660208] станет доступна за менее длительный период, но база будет работать быстрейе |
# Возможно, это проводки за списания и тогда через [конструктор отчётов|CarbonBilling:Конструктор отчетов] постарайтесь понять структуру нрасхода: у каких абонентов больгше всего проводок, по каким операциям и тд. Возможно, где-то в настройках услуг или ведении абонентов допущена ошибка. |
h4. RADIUS_SESSIONS |
В таблиц хранится история RADIUS-авторизций. Если таблица слишком разраслась, настройте [период хранения исторических данных в базе|https://docs.carbonsoft.ru/pages/viewpage.action?pageId=107577360] - умнеьшите его. Если это не помогло, возможно проблема так же где-то в авторизациях или оборудованиии и вероятно помимо таблицы с историей авторизаций, у Вас так же разрастётся EVENTS_STACK. |
В таблице хранится история RADIUS-авторизаций. Если таблица слишком разрослась, настройте [период хранения исторических данных в базе|https://docs.carbonsoft.ru/pages/viewpage.action?pageId=107577360] - уменьшите его. Если это не помогло - возможно, проблема так же где-то в авторизациях или оборудованиии и, вероятно, помимо таблицы с историей авторизаций, у Вас так же разрастётся 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 (отрицательный баланс)) # Когда проблема с доступом будет решена, проанализируйте логи одного или нескольких абонентов, чтобы понять что произошло и почему абонентов не оказалось в списке авторизованных или заблокированных. |