|
Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.
|
Изменения (18)
просмотр истории страницыНиже описаны возможные причины с которыми сталкивалась техподдержка и методы решения |
{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. |
... |
{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 с 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' |
... |
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 |
... |
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 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* и они часто повторяются по одним и тем же адресам, значит проблема в этом. |
... |
h3. Ситуация |
|
Вы создали нового абонента, Вас перевело в его карточку и над номером договора долго не пропадает сообщение что абонент в обработке: !subscriber_in_progress.png|border=1,width=400! |
Это говорит о том, что [итерация Воркера|CarbonBilling:Worker] Воркера|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:Добавление диска под БД] с высокой скоростью доступа. |
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 (отрицательный баланс)) # Когда проблема с доступом будет решена, проанализируйте логи одного или нескольких абонентов, чтобы понять что произошло и почему абонентов не оказалось в списке авторизованных или заблокированных. |