Jump to content
Калькуляторы

Freeradius DHCP нагрузка.

Всем привет. Начали мы значит запускать у себя Freeradius DHCP, постепенно. Пользователей через радиус включил около 100. И раз в несколько дней, радиус захлебывается с такими сообщениями:

Sun Jun  9 22:41:16 2019 : Error: 297 requests have been waiting in the processing queue for 38 seconds.  Check that all databases are running properly!
Sun Jun  9 22:41:16 2019 : Error: Unresponsive child for request 107175, in component post-auth module perl
Sun Jun  9 22:41:16 2019 : WARNING: (106763) WARNING: Module rlm_perl became unblocked
Sun Jun  9 22:41:16 2019 : Error: Unresponsive child for request 107183, in component post-auth module perl
Sun Jun  9 22:41:17 2019 : WARNING: (106767) WARNING: Module rlm_perl became unblocked
Sun Jun  9 22:41:17 2019 : Error: 299 requests have been waiting in the processing queue for 38 seconds.  Check that all databases are running properly!
Sun Jun  9 22:41:17 2019 : Error: Unresponsive child for request 107188, in component post-auth module perl
Sun Jun  9 22:41:17 2019 : WARNING: (106774) WARNING: Module rlm_perl became unblocked
Sun Jun  9 22:41:17 2019 : Error: Unresponsive child for request 107196, in component post-auth module perl
Sun Jun  9 22:41:18 2019 : WARNING: (106779) WARNING: Module rlm_perl became unblocked
Sun Jun  9 22:41:18 2019 : Error: 301 requests have been waiting in the processing queue for 38 seconds.  Check that all databases are running properly!
Sun Jun  9 22:41:18 2019 : Error: Unresponsive child for request 107202, in component post-auth module perl
Sun Jun  9 22:41:19 2019 : WARNING: (106790) WARNING: Module rlm_perl became unblocked

 

При чем может двое суток нормально проработать, а может и сутки. Как только перезапускаю службу, то тут же становится все нормально. alive у пользователей в таком случае стоит 10 минут. Версия радиус 3.0.19. В mysql бешенной нагрузки не наблюдалось. И самое интересное, что в момент начала проблемы у радиуса начинается жор памяти:

mem.thumb.png.24f6a951b7208499d2b1bdd73e91b26c.png

 

Куда ему вообще столько памяти, когда он работает только как dhcp?

 

Вот приложил конфиги:

abills_default

dhcp

perl

radiusd.conf

 

Perl кстати скомпилирован без -Dusethreads. Может в этом причина? 

 

Подскажите пожалуйста, куда в какую сторону вообще смотреть в таком случае? Может радиус какие старые данные не очищает и копит их в памяти.

 

Share this post


Link to post
Share on other sites

эмм, а что у Вас на rlm_perl? а вообще, судя по симптомам виснут соединения между БД и ФР...

Share this post


Link to post
Share on other sites
2 часа назад, NewUse сказал:

эмм, а что у Вас на rlm_perl? а вообще, судя по симптомам виснут соединения между БД и ФР...

Выдача адресов. Вообще радиус у меня работает в связке с абиллсом. да бд вроде нормально себя чувствует. в моменты ошибок в ФР, ошибок в бд нет. да и странно то, что ФР может впасть в ступор в любое время, и когда нагрузки мало и когда много. По сути, если бы проблема в бд была, то радиус отваливался бы каждый раз, когда нагрузка возрастала бы?

Share this post


Link to post
Share on other sites

Вот сейчас сколько потребляет, сейчас все хорошо работает.

mem.thumb.png.b0b8c9253ae6f3588575cd116375ebf3.png

Share this post


Link to post
Share on other sites
3 часа назад, roma33rus сказал:

Выдача адресов. Вообще радиус у меня работает в связке с абиллсом. да бд вроде нормально себя чувствует. в моменты ошибок в ФР, ошибок в бд нет. да и странно то, что ФР может впасть в ступор в любое время, и когда нагрузки мало и когда много. По сути, если бы проблема в бд была, то радиус отваливался бы каждый раз, когда нагрузка возрастала бы? 

Где-то у вас race condition зарылся. У вас адрес в пуле каким образом для клиента выбирается и резервируется?

Share this post


Link to post
Share on other sites
16 минут назад, taf_321 сказал:

Где-то у вас race condition зарылся. У вас адрес в пуле каким образом для клиента выбирается и резервируется?

Адрес клиенту мы привязываем статически, либо с привязкой по МАК адресу, либо с привязкой к коммутатору и порту. Резерв ведется в базе на основе поднятой сессии биллинга. Если абонент успешно получает ip адрес, то биллинг, заносит связку в базу и поднимает сессию. Кстати сейчас alive на абонентов стоит 10 минут (то есть каждые 5 минут абонент продляет аренду ip), по логике биллинга сессия через 1 час закрывается и удаляется. Только вот сейчас по истечении 1 часа неактивности абонента сессия нифига не закрывается. Где-то в этой степи и кроется проблема может?

Share this post


Link to post
Share on other sites
3 часа назад, roma33rus сказал:

Выдача адресов. Вообще радиус у меня работает в связке с абиллсом. да бд вроде нормально себя чувствует. в моменты ошибок в ФР, ошибок в бд нет. да и странно то, что ФР может впасть в ступор в любое время, и когда нагрузки мало и когда много. По сути, если бы проблема в бд была, то радиус отваливался бы каждый раз, когда нагрузка возрастала бы?

 

ну так зачем перл, делайте чере rlm_sql напрямую...

вечером посмотрю перл-конфиг, но вроде бы Вам перл нафиг не нужен...

Share this post


Link to post
Share on other sites
10 минут назад, NewUse сказал:

 

ну так зачем перл, делайте чере rlm_sql напрямую...

вечером посмотрю перл-конфиг, но вроде бы Вам перл нафиг не нужен...

У нас так биллинг работает стандартно. Настройка по их руководству проходила.

Share this post


Link to post
Share on other sites
4 часа назад, roma33rus сказал:

да и странно то, что ФР может впасть в ступор в любое время, и когда нагрузки мало и когда много. По сути, если бы проблема в бд была, то радиус отваливался бы каждый раз, когда нагрузка возрастала бы? 

я говорил о возможных проблемах сети/сокетов, именно связи, а не БД/радиуса в отдельности, коннекшен таймаут стоит в настройках перлового драйвера к бд?

Share this post


Link to post
Share on other sites
13 минут назад, NewUse сказал:

я говорил о возможных проблемах сети/сокетов, именно связи, а не БД/радиуса в отдельности, коннекшен таймаут стоит в настройках перлового драйвера к бд?

в файле rlm_perl.pl есть такая строчка на подключение к базе и таймаута там нет:

  my $db = Abills::SQL->connect($conf{dbtype}, $conf{dbhost}, $conf{dbname}, $conf{dbuser}, $conf{dbpasswd});

 

Share this post


Link to post
Share on other sites

да, уже смотрю, там глубоковато зарыт драйвер...

Share this post


Link to post
Share on other sites

Вот нашел в main.pm строчку подключения к БД

$db = DBI->connect_cached( "DBI:mysql:database=$dbname;host=$dbhost;mysql_client_found_rows=0", "$dbuser"
    , "$dbpasswd", { Taint => 1, private_scope_key => $attr->{SCOPE} || 0 } ) 

 никаких таймаутов.

Share this post


Link to post
Share on other sites

Вот, а надо добавить: у меня, правда с oracle, бывало, что соединение зависало, там надо было через keep-alive настраивать ибо драйвер не умеет таймаут.

$db = DBI->connect_cached( "DBI:mysql:database=$dbname;host=$dbhost;mysql_client_found_rows=0;mysql_connect_timeout=600", "$dbuser"
    , "$dbpasswd", { Taint => 1, private_scope_key => $attr->{SCOPE} || 0 } ) 

 

Единственное, я бы наверное в rlm_perl.pl правил, чтоб на остальные скрипты не повлиять:

use DBI;
my $db = DBI->connect("DBI:mysql:database=$dbname;host=$dbhost;mysql_client_found_rows=0;mysql_connect_timeout=6", "$dbuser"
    , "$dbpasswd");

 

 

Попробуйте так.

 

Edited by NewUse
уменьшил таймаут до 6с.

Share this post


Link to post
Share on other sites

Спасибо, попробую поменять. У Вас тоже Abills?

Share this post


Link to post
Share on other sites

нет, у меня не abils

 

Да, надо посмотреть запросы, добавить логирование времени отправки и коммита, возможно дубли, или что-то ещё, и уменьшить таймаут до 3-5секунд, от 600 толкуне будет, в самом радиусе встроен таймаут в ~30 секунд

Edited by NewUse

Share this post


Link to post
Share on other sites

Хорошо. я пока попробую с таймаутом поиграюсь. Посмотрим как он себя вести будет.

Share this post


Link to post
Share on other sites

Всем привет еще раз. Поставил я таймаут в rlm_perl. Сутки пока полет нормальный, ошибок не было. а вот память как он жрал, так и жрет. Куда ему вообще столько памяти то? я уж все лишние модули поотключал. Стоит паниковать при таком расходе?

 

screenshot-monitoring.tvinnet.ru-2019_06.18-09-48-42.thumb.png.580ea8f5fa72b1cccb7241ba43a3c82d.png

 

Edited by roma33rus

Share this post


Link to post
Share on other sites

скорее всего жрёт перл, и проблема в БД, таймаут это всего лишь костыль, чтоб разобраться в проблеме нужно разобраться, почему тормозит БД.

Share this post


Link to post
Share on other sites

Да если бы проблема была в производительности базы, то ошибки были бы всегда при высокой нагрузки. А так по факту у меня при нагрузке может и хорошо все работать. Я все-таки наверно попробую perl пересобрать с -Dusethreads. Или оно вообще никак не повлияет? Просто где-то прочитал, что если perl собран без этой опции, то из конфига модуля perl не учитываются переменные:

max_clones = 128
start_clones = 32
min_spare_clones = 5
max_spare_clones = 32
max_request_per_clone = 64

 

Share this post


Link to post
Share on other sites
19 минут назад, roma33rus сказал:

Да если бы проблема была в производительности базы, то ошибки были бы всегда при высокой нагрузки.

Ошибки могут быть из-за dead-lock от конкретных запросов, а не от нагрузки.

 

20 минут назад, roma33rus сказал:

Я все-таки наверно попробую perl пересобрать с -Dusethreads.

Хуже точно не будет

21 минуту назад, roma33rus сказал:

Или оно вообще никак не повлияет?

Скорее всего не повлияет, ну может память чуть медленнее станет течь.

Share this post


Link to post
Share on other sites
2 часа назад, NewUse сказал:

Ошибки могут быть из-за dead-lock от конкретных запросов, а не от нагрузки.

Хм. Для меня это вновинку, надо почитать инфо про это. Спасибо за наводку.

Share this post


Link to post
Share on other sites

Пересобрался я значит perl с -Dusethreads. теперь радиус падает с ошибкой 

radiusd[43025]: segfault at 7ff9ac917140 ip 00007ff9ac917140 sp 00007ff9af933638 error 14 in libfreeradius-dhcp.so[7ff9acd25000+7000]

Что-то вообще не клеится у меня.

 

Появляется мысль уже попробовать запуститься на 2 версии радиуса.

Edited by roma33rus

Share this post


Link to post
Share on other sites
1 час назад, roma33rus сказал:

Пересобрался я значит perl с -Dusethreads. теперь радиус падает с ошибкой 

попробуйте теперь пересобрать радиус с новым perl

1 час назад, roma33rus сказал:

Появляется мысль уже попробовать запуститься на 2 версии радиуса. 

а в чём смысл?

 

1 час назад, roma33rus сказал:

Пересобрался я значит perl с -Dusethreads

а где Вы вычитали, что треды поддерживаются в rlm_perl

ну и проверяйте конфиг, если поддерживаются.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now