[roma33rus]

Всем привет. Начали мы значит запускать у себя 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 бешенной нагрузки не наблюдалось. И самое интересное, что в момент начала проблемы у радиуса начинается жор памяти:

 

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

 

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

abills_default

dhcp

perl

radiusd.conf

 

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

 

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

 

[NewUse]

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

[roma33rus]

2 часа назад, NewUse сказал:

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

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

[roma33rus]

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

[taf_321]

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

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

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

[roma33rus]

16 минут назад, taf_321 сказал:

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

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

[NewUse]

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

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

 

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

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

[roma33rus]

10 минут назад, NewUse сказал:

 

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

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

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

[NewUse]

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

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

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

[roma33rus]

13 минут назад, NewUse сказал:

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

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

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

 

[NewUse]

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

[roma33rus]

Вот нашел в 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 } ) 

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

[NewUse]

Вот, а надо добавить: у меня, правда с 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");

 

 

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

 

Изменено 10 июня, 2019 пользователем NewUse
уменьшил таймаут до 6с.

[roma33rus]

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

[NewUse]

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

 

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

Изменено 10 июня, 2019 пользователем NewUse

[roma33rus]

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

[roma33rus]

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

 

 

Изменено 18 июня, 2019 пользователем roma33rus

[~AsmodeuS~]

Поставте мониторинг радиуса чтобы понять в чем затык

 

 

http://abills.net.ua:8090/pages/viewpage.action?pageId=11403799

 

 

[roma33rus]

10 минут назад, ~AsmodeuS~ сказал:

Поставте мониторинг радиуса чтобы понять в чем затык

 

 

http://abills.net.ua:8090/pages/viewpage.action?pageId=11403799

 

 

да, можно попробовать, спасибо.

[NewUse]

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

[roma33rus]

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

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

 

[NewUse]

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

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

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

 

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

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

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

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

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

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

[roma33rus]

2 часа назад, NewUse сказал:

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

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

[roma33rus]

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

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

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

 

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

Изменено 20 июня, 2019 пользователем roma33rus

[NewUse]

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

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

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

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

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

а в чём смысл?

 

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

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

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

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