BiTel

Добрый день!

На email администратору приходит ошибка:

[BGInetAccounting] RADIUS сервер не успевает обрабатывать запросы

В рамках отведенного переменными количества потоков threadCount и размером очереди обработки maxQueueSize RADIUS сервер не успеевает производить обработку аккаунтинг запросов.
Возможная причина - загруженность базы данных.

Сервер не загружен. Но абоненты не могут подключиться. Какие причины этой ошибки? Что смотреть? Какие настройки?

характеристики сервара, всякие top конфиги аккаунтинга, какая схема обработки трафика, когда происходит, чем считается трафик

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Характеристики сервера имеют разве значение, если я написал, что нагрузка на процессор минимальна.

top конфиги - это что? Имеется ввиду вот это?
<!-- Размер буфера приема слушателя -->
<param name="recvBufferSize">1 * 1024 * 1024</param>
<!-- Рекомендуемый SO_RCVBUF сокета -->
<param name="soRCVBUF"></param>
<!-- Количество потоков-обработчиков -->
<param name="threadCount">100</param>
<!-- Максимальное количество пакетов в очереди на обработку -->
<param name="maxQueueSize">1000</param>
<!-- Передача процессора -->
<param name="processor">radiusProcessor</param>
<!-- Режим работы, RadiusListener.Mode.accounting -->
<param name="mode">RadiusListener.Mode.accounting</param>
<!-- Передача setup -->
<param name="setup">setup</param>
<!-- Передача dataLogger -->
<param name="dataLogger">radiusDataLogger</param>


Как я понимаю проблема не в подсчете трафика - у нас очень мало абонентов с тарифами по трафику - буквально несколько штук. Я так думаю проблема именно в аккаунтинге с радиуса при подключении/отключении абонентов по pppoe на BRAS.

Какая версия/билд? Может быть старый?

Только RADIUS используется, telnet/ssh нет?
Что в логах, BGInetAccess/log/error.log BGInetAccounting/log/error.log, например.
Пробовали перезапустить приложения?

Посмотрите, не много ли файлов в activemq/data/kahadb. Если много - попробуйте остановить activemq, переименовать папку и снова запустить, затем перезапустить BGBillingServer, InetAccess, InetAccounting.

У меня такая ошибка приходит, начиная с мая прошлого года один раз на границе суток при смене месяца. В январе 2014 стала появляться на границе суток в течение месяца. В логах accounting ошибка :


Увеличение параметров threadCount и maxQueueSize иногда помогает, иногда - нет. В настоящий момент значения этих параметров для accounting - 100 и 600 соответственно. Количество абонентов, активных в биллинге - около 700, в логах mysql ошибок нет, процессов со статусом sleep в пределах 50, настроена репликация. В указанное время наблюдается увеличение трафика на сервере в три раза, в среднем с 10 kBps до 30 kBps. Используется только RADIUS, 1 NAS cisco isg. Файлов в activemq/data/kahadb - 11.

Похожая тема - viewtopic.php?f=44&t=8177&hilit=threadCount

На cisco дефолтовая настройка в части radius-server timeout (5 секунд). Возможно ли, как вариант, увеличить этот таймаут, для решения проблемы?

Сообщения о радиусе при ошибке:



Текущий статус accounting:



Версия биллинга:

up

При таком объеме не должно быть. Посмотрите что в MySQL SHOW PROCESSLIST покажет во время этих сообщений.
Может быть какие-то SQL команды выполняются медленно. Если да - возможно проблема в настройке MySQL или в даже жестком диске (и такое было).

Спасибо за ответ, посмотрю в сторону производительности ввода-вывода и mysql. А имеет ли смысл дальше увеличивать параметры threadCount и maxQueueSize и каков принцип изменения этих параметров?
В последнее время сообщения появляются вразнобой в течение дня (на границе суток их пока нет), в среднем раз в два дня.