forum.bitel.ru
http://forum.bitel.ru/

Radius при кретических нагрузках
http://forum.bitel.ru/viewtopic.php?f=5&t=3599
Страница 1 из 1

Автор:  skyb [ 15 фев 2010, 10:04 ]
Заголовок сообщения:  Radius при кретических нагрузках

Ув. разработчики. Не могли бы вы расписать
http://bgbilling.ru/v5.1/doc/ch03s09s04.html пункт 9.4.4 если можно то напримере
допустим у меня 500 запросов на авторизацию...в соотношение чего нужно ставить числа в
auth.thread.count и acct.thread.count
auth.thread.must.be.free.count и acct.thread.must.be.free.count

Автор:  Администратор [ 15 фев 2010, 14:22 ]
Заголовок сообщения:  Re: Radius при кретических нагрузках

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

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

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

Автор:  iros [ 15 фев 2010, 15:01 ]
Заголовок сообщения:  Re: Radius при кретических нагрузках

И еще вопрос: По пункту 9.4.5 Оптимизация работы с базой данных.

Цитата:
detail.compress.2.0-23=SKIP
detail.compress.23.0-23=0
detail.compress.24.0-23=0

Эти опции используются в конфигурации модуля или в узле Конфигурация тарифа ?
Т.е. могу ли я прописать их только для конкретного тарифа ?

Автор:  Администратор [ 15 фев 2010, 15:36 ]
Заголовок сообщения:  Re: Radius при кретических нагрузках

Код:
Правила "свёртки" таблицы session_detail определяются в конфигурации модуля следующим образом:

Автор:  skyb [ 15 фев 2010, 15:44 ]
Заголовок сообщения:  Re: Radius при кретических нагрузках

А если нет учета по времени можно же эту услугу свернуть?

Автор:  Администратор [ 15 фев 2010, 16:18 ]
Заголовок сообщения:  Re: Radius при кретических нагрузках

Вопрос не понял. "Эта" - это какая услуга? "Учёт по времени" - это что такое?

Автор:  snark [ 15 фев 2010, 17:01 ]
Заголовок сообщения:  Re: Radius при кретических нагрузках

учет времени есть всегда, т.к. его услуга обязательная, ЕМНИП

Автор:  skyb [ 16 фев 2010, 06:06 ]
Заголовок сообщения:  Re: Radius при кретических нагрузках

вот от сюда и вопрос-если нет тарификации по услуги время можно ли ее сворачивать?

Автор:  stark [ 16 фев 2010, 13:54 ]
Заголовок сообщения:  Re: Radius при кретических нагрузках

skyb писал(а):
вот от сюда и вопрос-если нет тарификации по услуги время можно ли ее сворачивать?

не совсем понятен термин сворачивать . услуга должна быть прописана на nas-е и цена должна быть в тарифе(0) . обязательно. даже если нет тарификации. это атавизм, но так работает

Автор:  Администратор [ 17 фев 2010, 12:55 ]
Заголовок сообщения:  Re: Radius при кретических нагрузках

Цитата:
вот от сюда и вопрос-если нет тарификации по услуги время можно ли ее сворачивать?

Да вообще скипайте её запись в БД, можно конечно. Первое дело :)

Автор:  skyb [ 17 фев 2010, 13:23 ]
Заголовок сообщения:  Re: Radius при кретических нагрузках

Администратор писал(а):
Цитата:
вот от сюда и вопрос-если нет тарификации по услуги время можно ли ее сворачивать?

Да вообще скипайте её запись в БД, можно конечно. Первое дело :)

Спасибо, сделал :-)

Автор:  skyb [ 27 май 2010, 15:19 ]
Заголовок сообщения:  Re: Radius при кретических нагрузках

В продолжение темы, последнее время начали часто сыпаться алармы о том что был игнорирован аккаунтинг запрос...такое происходит после перезапуска радиуса (что хоть как то в голову укладывается), но 2 раза уже было само по себе. Куда копать??

Автор:  stark [ 27 май 2010, 18:07 ]
Заголовок сообщения:  Re: Radius при кретических нагрузках

skyb писал(а):
В продолжение темы, последнее время начали часто сыпаться алармы о том что был игнорирован аккаунтинг запрос...такое происходит после перезапуска радиуса (что хоть как то в голову укладывается), но 2 раза уже было само по себе. Куда копать??

acct.thread.count

Автор:  skyb [ 27 май 2010, 18:12 ]
Заголовок сообщения:  Re: Radius при кретических нагрузках

stark писал(а):
skyb писал(а):
В продолжение темы, последнее время начали часто сыпаться алармы о том что был игнорирован аккаунтинг запрос...такое происходит после перезапуска радиуса (что хоть как то в голову укладывается), но 2 раза уже было само по себе. Куда копать??

acct.thread.count

Цитата:

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

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

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

вот так вот ставил. непонимаю

Страница 1 из 1 Часовой пояс: UTC + 5 часов [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/