BiTel

Форум BiTel		 bgbilling.ru     docs.bitel.ru     wiki.bitel.ru     dbinfo.bitel.ru     bgcrm.ru     billing.bitel.ru     bitel.ru    
Текущее время: 28 апр 2024, 16:53

Сообщения без ответов | Активные темы


Список форумов » BGBilling » Модули Интернета » Модуль DialUp (VPN)

Часовой пояс: UTC + 5 часов [ Летнее время ]



Начать новую тему Ответить на тему  Страница 1 из 1
  [ Сообщений: 17 ] 
  Версия для печати Пред. тема | След. тема 
Автор Сообщение
Cromeshnic
СообщениеДобавлено: 31 май 2011, 07:59 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Версия радиуса:
version 5.1 build 276 from 07.04.2011 12:20:07

Сегодня массово сбрасывали сессии на NAS-ах, словили такую проблему:
радиус съел все разрешенные коннекты к базе и не освобождал их до перезагрузки.

Сделал jstack, jmap, сохранили логи, сел разбираться.

В jstack половина потоков висит на ожидании получения коннекта:

Код:
"radiusListener-p-3-t-311" prio=10 tid=0x0000000041cc2800 nid=0x2c75 in Object.wait() [0x00007fd229ad9000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Object.java:485)
        at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:942)
        - locked <0x00007fd28cb2fb60> (a org.apache.commons.pool.impl.GenericObjectPool)
        at ru.bitel.bgbilling.server.util.DefaultServerSetup.getDBConnectionFromPool(DefaultServerSetup.java:499)
        at ru.bitel.bgbilling.server.util.DefaultServerSetup.getDBTrashOrMasterConnectionFromPool(DefaultServerSetup.java:703)
        at bitel.billing.server.script.bean.ScriptMachine.logFunctionProcess(ScriptMachine.java:258)
        at bitel.billing.server.script.bean.ScriptMachine.runScript(ScriptMachine.java:163)
        at bitel.billing.server.script.bean.event.EventProcessor.processContractEvent(EventProcessor.java:313)
        at bitel.billing.server.script.bean.event.EventProcessor.processEvent(EventProcessor.java:231)
        at bitel.billing.server.script.bean.event.EventProcessor.processEvent(EventProcessor.java:215)
        at bitel.billing.server.script.bean.event.EventProcessor.processEvent(EventProcessor.java:194)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusProcessor.accessRequest(RadiusProcessor.java:328)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusListenerWorker.run(RadiusListenerWorker.java:130)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:662)
        at ru.bitel.common.worker.WorkerThread.run(WorkerThread.java:40)


Вторая половина висит на ожидании входа в synchronized метод bitel.billing.server.processor.LC_LimitChecker.canComeIn() :

Код:
"radiusListener-p-3-t-314" prio=10 tid=0x0000000040d94800 nid=0x2c78 waiting for monitor entry [0x00007fd2297d5000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at bitel.billing.server.processor.LC_LimitChecker.canComeIn(LC_LimitChecker.java:73)
        - waiting to lock <0x00007fd28cbb8b58> (a ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor$1)
        at ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor.authorization(DialUpRadiusProcessor.java:890)
        at ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor.authorization(DialUpRadiusProcessor.java:1)
        at ru.bitel.bgbilling.kernel.network.radius.AbstractRadiusProcessor.authenticationImpl(AbstractRadiusProcessor.java:411)
        at ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor.authenticationImpl(DialUpRadiusProcessor.java:594)
        at ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor.authenticationImpl(DialUpRadiusProcessor.java:1)
        at ru.bitel.bgbilling.kernel.network.radius.AbstractRadiusProcessor.authentication(AbstractRadiusProcessor.java:192)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusSession.authentication(RadiusSession.java:114)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusSession.accessRequest(RadiusSession.java:92)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusProcessor.accessRequest(RadiusProcessor.java:316)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusListenerWorker.run(RadiusListenerWorker.java:130)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:662)
        at ru.bitel.common.worker.WorkerThread.run(WorkerThread.java:40)


А заткнулось всё на этом потоке:

Код:
"radiusListener-p-3-t-319" prio=10 tid=0x0000000041c67800 nid=0x2c7d in Object.wait() [0x00007fd2292d0000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Object.java:485)
        at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:942)
        - locked <0x00007fd28cb2fb60> (a org.apache.commons.pool.impl.GenericObjectPool)
        at ru.bitel.bgbilling.server.util.DefaultServerSetup.getDBConnectionFromPool(DefaultServerSetup.java:499)
        at bitel.billing.server.processor.LC_CheckingLogin.getStatus(LC_CheckingLogin.java:39)
        at bitel.billing.server.processor.LC_CheckingLogin.canLoginComeIn(LC_CheckingLogin.java:162)
        at bitel.billing.server.processor.LC_LimitChecker.canComeIn(LC_LimitChecker.java:79)
        - locked <0x00007fd28cbb8b58> (a ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor$1)
        at ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor.authorization(DialUpRadiusProcessor.java:890)
        at ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor.authorization(DialUpRadiusProcessor.java:1)
        at ru.bitel.bgbilling.kernel.network.radius.AbstractRadiusProcessor.authenticationImpl(AbstractRadiusProcessor.java:411)
        at ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor.authenticationImpl(DialUpRadiusProcessor.java:594)
        at ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor.authenticationImpl(DialUpRadiusProcessor.java:1)
        at ru.bitel.bgbilling.kernel.network.radius.AbstractRadiusProcessor.authentication(AbstractRadiusProcessor.java:192)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusSession.authentication(RadiusSession.java:114)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusSession.accessRequest(RadiusSession.java:92)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusProcessor.accessRequest(RadiusProcessor.java:316)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusListenerWorker.run(RadiusListenerWorker.java:130)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:662)
        at ru.bitel.common.worker.WorkerThread.run(WorkerThread.java:40)


Как я понимаю, при вызове метода ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor.authorization() тред уже берёт один коннект к базе из пула.
Затем он запускает метод bitel.billing.server.processor.LC_LimitChecker.canComeIn(), в недрах которого коннект к базе получается заново.
Получается, что первый коннект он успел схватить, а на получении второго застрял, т.к. они закончились.
Дальше т.к. метод canComeIn() - синхронизирован, то все остальные потоки авторизации затыкаются либо на нём, либо на получении коннекта к базе.
Как-то так, в целом. Правда не совсем понятно, как куча потоков авторизации, ожидающих canComeIn(), получила первый коннект к мускулю, а наш поток так и остался ждать своей очереди.

Вот.
Могу выслать на почту, если надо:
    collector.log.err.2011-05-31-07:26
    connection.log.err.2011-05-31-07:26
    error.log.err.2011-05-31-07:26
    innodbstat.log.2011-05-31-07:26
    mq.log.err.2011-05-31-07:26
    mysql.proc.2011-05-31-07:26
    processor.log.err.2011-05-31-07:26
    radius.jmap.2011-05-31-07:26
    radius.jstack.2011-05-31-07:26
    radius.log.err.2011-05-31-07:26
    radius.out.err.2011-05-31-07:26
    rad_ps.2011-05-31-07:26
    script.log.err.2011-05-31-07:26
    status.log.2011-05-31-07:26
Вернуться к началу
 Профиль  
 
Cromeshnic
СообщениеДобавлено: 02 июн 2011, 11:13 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
up
Вернуться к началу
 Профиль  
 
Amir
СообщениеДобавлено: 07 июн 2011, 21:16 
Не в сети
Разработчик
Аватара пользователя

Зарегистрирован: 19 дек 2006, 21:04
Сообщения: 5970
Карма: 256
Выложили обновление радиуса, где лишние соединение к базе не берется.
А сколько в radius.properties auth.thread.count, db.maxActive?
Вернуться к началу
 Профиль  
 
Cromeshnic
СообщениеДобавлено: 08 июн 2011, 06:34 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Сейчас так:
Код:
db.maxActive=1500
auth.thread.count=900
acct.thread.count=500


На момент ошибки не помню уже, возможно поменьше чуть.
Вложение:
graph_image.png
graph_image.png [ 34.94 КБ | Просмотров: 7604 ]


Столько много нужно для всяких внезапных массовых сбросов и т.п.
Вернуться к началу
 Профиль  
 
snark
СообщениеДобавлено: 08 июн 2011, 16:10 
Не в сети
Клиент

Зарегистрирован: 12 фев 2008, 18:10
Сообщения: 3951
Карма: 249
Cromeshnic писал(а):
Сейчас так:
Код:
auth.thread.count=900
acct.thread.count=500


Оппа! Понимаю что можно писать хоть 100500, но их вроде максимум 110 может быть, не?
Вернуться к началу
 Профиль  
 
Amir
СообщениеДобавлено: 08 июн 2011, 17:05 
Не в сети
Разработчик
Аватара пользователя

Зарегистрирован: 19 дек 2006, 21:04
Сообщения: 5970
Карма: 256
Похоже что случилось так, что потоков было 900, а соединений к базе взялось в два раза больше. Теперь, без лишнего получения будет получше.

Цитата:
Оппа! Понимаю что можно писать хоть 100500, но их вроде максимум 110 может быть, не?
На максимум там проверки нет.

Цитата:
auth.thread.count=900
А увеличенное количество сильно помогает? Там же, если потоки не успевают обрабатывать, все равно задача кладется в очередь.
Вернуться к началу
 Профиль  
 
snark
СообщениеДобавлено: 08 июн 2011, 18:14 
Не в сети
Клиент

Зарегистрирован: 12 фев 2008, 18:10
Сообщения: 3951
Карма: 249
Amir писал(а):
Цитата:
Оппа! Понимаю что можно писать хоть 100500, но их вроде максимум 110 может быть, не?

На максимум там проверки нет.

Я правильно понимаю что можно написать 100500 (т.к. нет проверки), но работать всеравно будет 110? Если нет, то как?
А еще лучше - разъясните раз и навсегда как оптимально высчитывать эти параметры исходя из того что нам дает "status".
Поймите правильно - _очень_ хочется подробностей, т.к. этот вопрос регулярно поднимается из за того что RADIUS для многих - основная часть системы.
Вернуться к началу
 Профиль  
 
Cromeshnic
СообщениеДобавлено: 09 июн 2011, 07:10 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
110 - это вообще откуда?

Amir писал(а):
А увеличенное количество сильно помогает? Там же, если потоки не успевают обрабатывать, все равно задача кладется в очередь.

Эмм, уже точно не помню, вроде стало лучше. Если кладёт в очередь, то откуда берутся auth ignore?

Вложение:
graph_image.png
graph_image.png [ 27 КБ | Просмотров: 7581 ]

Хотя на картинке auth ignore возможно был во время бага.

Это мы сбрасывали пачками пользователей по NAS-ам. Заходим на NAS - сбрасываем всех - ждём, пока радиус всех прожуёт - заходим на следующий...

snark писал(а):
Поймите правильно - _очень_ хочется подробностей, т.к. этот вопрос регулярно поднимается из за того что RADIUS для многих - основная часть системы.

Кстати да, все настройки правим по наитию.
Вернуться к началу
 Профиль  
 
Amir
СообщениеДобавлено: 09 июн 2011, 13:23 
Не в сети
Разработчик
Аватара пользователя

Зарегистрирован: 19 дек 2006, 21:04
Сообщения: 5970
Карма: 256
Цитата:
Если кладёт в очередь, то откуда берутся auth ignore?

Это зависит от параметра auth.thread.queue, который по умолчанию равен количеству потоков.
Если очередь (а в очередь задача попадает, если нет ни одного свободного потока для работы) становится больше чем auth.thread.queue, начинаются ignore.
Вернуться к началу
 Профиль  
 
Amir
СообщениеДобавлено: 09 июн 2011, 13:35 
Не в сети
Разработчик
Аватара пользователя

Зарегистрирован: 19 дек 2006, 21:04
Сообщения: 5970
Карма: 256
Я не могу сказать, какое значение будет оптимальным в конкретном случае.
auth.thread.count просто означает, какое максимальное количество потоков будет одновременно будут обрабатывать пакеты, т.е. это также означает сколько потоков будут одновременно работать с базой. Большее, чем ядер, количество потоков выигрывает в основном за счет задержек ввода/вывода, в том числе общения по сети (например, пока один поток ждет ответа от mysql, другой может что-нибудь делать).
auth.thread.queue - максимальный размер очереди, при превышении которого радиус начинает игнорить пакеты. (Чтобы не съесть всю память и для авторизации - так-как у наса может выйти таймаут ответа, пока радиус доберется до задачи, тогда задача выполнится в пустую).
Вернуться к началу
 Профиль  
 
Cromeshnic
СообщениеДобавлено: 09 июн 2011, 14:32 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Спасибо.
Я про auth.thread.queue не знал. В доках ничего нет про это: http://bgbilling.ru/v5.1/doc/ch13s09s03.html
Вернуться к началу
 Профиль  
 
snark
СообщениеДобавлено: 09 июн 2011, 15:39 
Не в сети
Клиент

Зарегистрирован: 12 фев 2008, 18:10
Сообщения: 3951
Карма: 249
Cromeshnic писал(а):
110 - это вообще откуда?

Отсюда:
Администратор писал(а):
auth.thread.must.be.free.count - определяет число "глотающих" потоков. Т.е. в случае заполнения пула какое-то число потоков должно оставаться свободным, чтобы "проглатывать" запросы, обеспечивая по факту освобождения БД обработку самых свежих. Делать эту переменную больше 5 смыслу особо нет, т.к. процесс быстрый.
acct.thread.must.be.free.count - можно оставить где-то 10 потоков, чтобы 10 потоков всегда обрабатывали пакеты старта и стопа.

А общее число потоков авторизации и аккаунтинга можно максимум в 110 поставить тех и тех. Вообще аккаунтинг менее приоритетен, но с другой стороны апдейтов идёт зато в 10 раз больше обычно чем авторизаций. Поэтому поровну в самый раз. Подобная конфигурация до 60 000 одновременных коннектов проверялась.

Дальнейшее увеличение потоков эффекта особого не даст (если только у вас не больше 100 ядер :) ). Потоки только помогают сгладить небольшой всплеск запросов. Если система объективно не успевает, наращивание числа потоков не поможет.


Amir писал(а):
auth.thread.queue - максимальный размер очереди

Оппа! Еще один параметр ...

Господа разработчики, пожалуйста, очень прошу, напишите уже наконец гайд по оптимизации RADIUS сервера с учетом всех указанных и не указанных (sic!) в доке параметров - всем от этого только лучше будет! Мы будем счастливы от того что RADIUS не падает, а Вы - от того что не надо одно и то же регулярно писать.
Вернуться к началу
 Профиль  
 
Amir
СообщениеДобавлено: 09 июн 2011, 16:14 
Не в сети
Разработчик
Аватара пользователя

Зарегистрирован: 19 дек 2006, 21:04
Сообщения: 5970
Карма: 256
Цитата:
Оппа! Еще один параметр ...

Это аналог acct.thread.must.be.free.count, просто более правильная его интерпретация.
Вернуться к началу
 Профиль  
 
Cromeshnic
СообщениеДобавлено: 01 авг 2011, 10:23 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Снова повторилось на границе месяцев при массовом сбросе. Причина такая же, только в другом методе.

Причина:
Код:
"radiusListener-p-3-t-775" prio=10 tid=0x00007fadacc0c000 nid=0x4c28 in Object.wait() [0x00007fad95ea3000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Object.java:485)
        at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:942)
        - locked <0x00007fadc08d6970> (a org.apache.commons.pool.impl.GenericObjectPool)
        at ru.bitel.bgbilling.server.util.DefaultServerSetup.getDBConnectionFromPool(DefaultServerSetup.java:499)
        at bitel.billing.server.processor.LC_CheckingLogin.loadConditions(LC_CheckingLogin.java:123)
        at bitel.billing.server.processor.LC_CheckingLogin.<init>(LC_CheckingLogin.java:34)
        at bitel.billing.server.processor.LC_LimitChecker.createCheckingLogin(LC_LimitChecker.java:92)
        at bitel.billing.server.processor.LC_LimitChecker.registerLogin(LC_LimitChecker.java:26)
        - locked <0x00007fadc09e4d20> (a ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor$1)
        at bitel.billing.server.processor.LC_LimitChecker.canComeIn(LC_LimitChecker.java:74)
        - locked <0x00007fadc09e4d20> (a ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor$1)
        at ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor.authorization(DialUpRadiusProcessor.java:892)
        at ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor.authorization(DialUpRadiusProcessor.java:1)
        at ru.bitel.bgbilling.kernel.network.radius.AbstractRadiusProcessor.authenticationImpl(AbstractRadiusProcessor.java:411)
        at ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor.authenticationImpl(DialUpRadiusProcessor.java:596)
        at ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor.authenticationImpl(DialUpRadiusProcessor.java:1)
        at ru.bitel.bgbilling.kernel.network.radius.AbstractRadiusProcessor.authentication(AbstractRadiusProcessor.java:192)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusSession.authentication(RadiusSession.java:114)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusSession.accessRequest(RadiusSession.java:92)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusProcessor.accessRequest(RadiusProcessor.java:316)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusListenerWorker.run(RadiusListenerWorker.java:130)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:662)
        at ru.bitel.common.worker.WorkerThread.run(WorkerThread.java:40)


Повисшие треды:
Код:
"radiusListener-p-3-t-714" prio=10 tid=0x00007fadac918000 nid=0x4740 waiting for monitor entry [0x00007fad31521000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at bitel.billing.server.processor.LC_LimitChecker.canComeIn(LC_LimitChecker.java:74)
        - waiting to lock <0x00007fadc09e4d20> (a ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor$1)
        at ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor.authorization(DialUpRadiusProcessor.java:892)
        at ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor.authorization(DialUpRadiusProcessor.java:1)
        at ru.bitel.bgbilling.kernel.network.radius.AbstractRadiusProcessor.authenticationImpl(AbstractRadiusProcessor.java:411)
        at ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor.authenticationImpl(DialUpRadiusProcessor.java:596)
        at ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor.authenticationImpl(DialUpRadiusProcessor.java:1)
        at ru.bitel.bgbilling.kernel.network.radius.AbstractRadiusProcessor.authentication(AbstractRadiusProcessor.java:192)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusSession.authentication(RadiusSession.java:114)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusSession.accessRequest(RadiusSession.java:92)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusProcessor.accessRequest(RadiusProcessor.java:316)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusListenerWorker.run(RadiusListenerWorker.java:130)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:662)
        at ru.bitel.common.worker.WorkerThread.run(WorkerThread.java:40)


Код:
version 5.1 build 287 from 08.06.2011 20:40:34
01.08.2011 00:40:06     2365    0       2095    270
Request accounts per minute start: 0; stop: 0; update: 0
Request auths per minute accept: 0; reject: 0
Netfow packets per minute: 8614
Ignore per minute auth: 125; update: 0
Antispam ban count: 0; used per minute: 0
FlowListener: queue_size: 0; threads_active: 0; largest: 20; core: 20; pool_size: 20; recv_socket_buf_size: 131 071; recv_buf_size: 8 388 608; packets: 28354151
Started: 28.07.2011 10:41:45    Uptime: 3 d 13:58:20
Memory total: 570 818 560; max: 715 849 728; free: 95 084 544
Memory pools:
Non-heap memory[Code Cache]: max: 50 331 648; used: 9 596 416; peek: 9 597 824
Heap memory[PS Eden Space]: max: 199 491 584; used: 61 051 544; peek: 258 801 664
Heap memory[PS Survivor Space]: max: 33 161 216; used: 4 325 376; peek: 89 440 296
Heap memory[PS Old Gen]: max: 536 870 912; used: 410 357 096; peek: 410 357 096
Non-heap memory[PS Perm Gen]: max: 88 080 384; used: 28 470 320; peek: 28 470 320
Thread count: 1725
Trees in cache: 162
Connections pool to Master status Idle: 0; Active: 1500; maxActive: 1500; maxIdle: 50


Код:
db.maxActive=1500
auth.thread.count=900
acct.thread.count=500
netflow.thread.count=20
auth.thread.must.be.free.count=30
acct.thread.must.be.free.count=50


По-идее надо чтобы thread.count кончалось раньше, чем коннекты к базе.
Уменьшил auth до 800 и acct до 300.
Вернуться к началу
 Профиль  
 
Cromeshnic
СообщениеДобавлено: 10 окт 2011, 07:37 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Видимо всё-таки правило auth.thread.count + acct.thread.count < db.maxActive не совсем верно, т.к. в коде куча мест, где на обработку одного пакета берётся второй (а может и третий?) коннект к базе, отчего при большой нагрузке может быть deadlock, что периодически и наблюдаем.

Например:

Код:
"radiusListener-p-3-t-295" prio=10 tid=0x00007fc34081d000 nid=0x78db in Object.wait() [0x00007fc307c83000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Object.java:485)
        at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:942)
        - locked <0x00007fc34b8053e0> (a org.apache.commons.pool.impl.GenericObjectPool)
        at ru.bitel.bgbilling.server.util.DefaultServerSetup.getDBConnectionFromPool(DefaultServerSetup.java:499)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusListenerWorker.run(RadiusListenerWorker.java:125)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:662)
        at ru.bitel.common.worker.WorkerThread.run(WorkerThread.java:40)

"radiusListener-p-3-t-294" prio=10 tid=0x00007fc340819800 nid=0x78d8 in Object.wait() [0x00007fc307e84000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Object.java:485)
        at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:942)
        - locked <0x00007fc34b8053e0> (a org.apache.commons.pool.impl.GenericObjectPool)
        at ru.bitel.bgbilling.server.util.DefaultServerSetup.getDBConnectionFromPool(DefaultServerSetup.java:499)
        at bitel.billing.server.script.bean.ScriptMachine.runScript(ScriptMachine.java:123)
        at bitel.billing.server.script.bean.event.EventProcessor.processContractEvent(EventProcessor.java:313)
        at bitel.billing.server.script.bean.event.EventProcessor.processEvent(EventProcessor.java:231)
        at bitel.billing.server.script.bean.event.EventProcessor.processEvent(EventProcessor.java:199)
        at bitel.billing.server.processor.dialup.DialUpSessionRealtime.setCalculatePeriod(DialUpSessionRealtime.java:1940)
        at ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor.authorization(DialUpRadiusProcessor.java:744)
        at ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor.authorization(DialUpRadiusProcessor.java:1)
        at ru.bitel.bgbilling.kernel.network.radius.AbstractRadiusProcessor.authenticationImpl(AbstractRadiusProcessor.java:411)
        at ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor.authenticationImpl(DialUpRadiusProcessor.java:596)
        at ru.bitel.bgbilling.modules.dialup.radius.DialUpRadiusProcessor.authenticationImpl(DialUpRadiusProcessor.java:1)
        at ru.bitel.bgbilling.kernel.network.radius.AbstractRadiusProcessor.authentication(AbstractRadiusProcessor.java:192)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusSession.authentication(RadiusSession.java:114)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusSession.accessRequest(RadiusSession.java:92)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusProcessor.accessRequest(RadiusProcessor.java:316)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusListenerWorker.run(RadiusListenerWorker.java:130)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:662)
        at ru.bitel.common.worker.WorkerThread.run(WorkerThread.java:40)

"radiusListener-p-3-t-257" prio=10 tid=0x00007fc340243800 nid=0x7895 in Object.wait() [0x00007fc30a3aa000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Object.java:485)
        at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:942)
        - locked <0x00007fc34b8053e0> (a org.apache.commons.pool.impl.GenericObjectPool)
        at ru.bitel.bgbilling.server.util.DefaultServerSetup.getDBConnectionFromPool(DefaultServerSetup.java:499)
        at ru.bitel.bgbilling.server.util.DefaultServerSetup.getDBTrashOrMasterConnectionFromPool(DefaultServerSetup.java:703)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusUtils.insertToLog(RadiusUtils.java:576)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusProcessor.accessRequest(RadiusProcessor.java:299)
        at ru.bitel.bgbilling.kernel.network.radius.RadiusListenerWorker.run(RadiusListenerWorker.java:130)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:662)
        at ru.bitel.common.worker.WorkerThread.run(WorkerThread.java:40)


Хотелось бы услышать от разработчиков, сколько максимум коннектов может требоваться для обработки 1 пакета.
Вернуться к началу
 Профиль  
 
Amir
СообщениеДобавлено: 10 окт 2011, 15:30 
Не в сети
Разработчик
Аватара пользователя

Зарегистрирован: 19 дек 2006, 21:04
Сообщения: 5970
Карма: 256
Максимум - должно быть два. Есть старые классы, которые для "универсальности" прямо в методе берут соединение и по окончании работы метода - завершают. Сложно поменять.
Вернуться к началу
 Профиль  
 
snark
СообщениеДобавлено: 10 окт 2011, 18:56 
Не в сети
Клиент

Зарегистрирован: 12 фев 2008, 18:10
Сообщения: 3951
Карма: 249
Тут:
Администратор писал(а):
Привет. У вас же 5.1 версия?
Код:
auth.thread.count=300                                                                                                                                                                                                                                       
acct.thread.count=200 

Вот это число потоков уменьшите до 20 и 30, больше смыслу нет.
Чтобы сглаживать колебание увеличьте размер очереди пакетов авторизации и аккаунтинга. До 200 и 300, например.
auth.thread.queue и acct.thread.queue
http://www.bgbilling.ru/v5.1/doc/ch13s0 ... l#d0e12831

Эти параметры с 5.1 вообще не нужны:
Код:
auth.thread.must.be.free.count=30                                                                                                                                                                                                                           
acct.thread.must.be.free.count=50
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  Страница 1 из 1
  [ Сообщений: 17 ] 

Список форумов » BGBilling » Модули Интернета » Модуль DialUp (VPN)

Часовой пояс: UTC + 5 часов [ Летнее время ]

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
POWERED_BY
Русская поддержка phpBB
[ Time : 0.788s | 54 Queries | GZIP : On ]