|
Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.
|
Изменения (3)
просмотр истории страницыНиже описаны возможные причины с которыми сталкивалась техподдержка и методы решения |
{toc:maxLevel=2} |
{info} В любом случае нестандартного поведения сервера полезно проверять системный лог |
... |
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} 39178 data pages; ARCH_ACCOUNT_STACK (146); 39178 data page slots; 87% average fill 75789 data pages; RADIUS_SESSIONS (254); 75789 data page slots; 86% average fill 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. 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 (отрицательный баланс)) # Когда проблема с доступом будет решена, проанализируйте логи одного или нескольких абонентов, чтобы понять что произошло и почему абонентов не оказалось в списке авторизованных или заблокированных. |