Abills падает радиус

[superb 54]

Всем привет. Abills 0.55b на Freebsd 7.2.

Начал падать радиус в 8 вечера. Вчера упал в 7-30 пока смотрел логи, гуглил. Запустил  в 8. Сегодня как по расписанию в то же время. Просто пропадает с запущенных сервисов. Стартует без проблем но хватает до следующего вечера(

Вот вчерашний кусок лога.

[Dimkers 1 601]

 логи молчат? Ротация логов на это время? Что в кроне на это время запланировано? Нагрузка в это время? Иопс? Дебаг? Скрипты абилса?

Відредаговано 2020-01-09 18:49:49 Dimkers

[superb 54]

Лог с radius.conf как раз когда упал вчера радиус. В кроне ничего не запланировано на это время. Около года аптайма, только логи чистил пол года назад.  radius.log не чистил, полтора гига весит. Изменений вообще никаких не делал.  Нагрузка 30% проца в часы пик, сетевая не отпадает.

Відредаговано 2020-01-09 19:07:12 superb

[Dimkers 1 601]

Ааа, мне всегда нравились люди, что скриншотют логи

Ну как бы ошибка пишет о отсутствии файла.

Відредаговано 2020-01-09 19:28:04 Dimkers

[wantmore 30]

Покажите df -h ?

Відредаговано 2020-01-09 19:33:02 wantmore

[superb 54]

vpnk# df -h
Filesystem            Size    Used   Avail Capacity  Mounted on
/dev/mirror/gm0s1a     38G    356M     34G     1%    /
devfs                 1.0k    1.0k      0B   100%    /dev
/dev/mirror/gm0s1d     38G     12M     35G     0%    /tmp
/dev/mirror/gm0s1e    191G     72G    104G    41%    /var
/dev/mirror/gm0s1f    182G     50G    117G    30%    /usr
 

[Dimkers 1 601]

Файлы из ошибки есть? Каждый раз одни и теже в ошибке?

Я с абилсом плотно не работал, может там встроенная ротация логов в это время идёт или ещё чето?

[superb 54]

7 минут назад, Dimkers сказав:

Файлы из ошибки есть? Каждый раз одни и теже в ошибке?

Я с абилсом плотно не работал, может там встроенная ротация логов в это время идёт или ещё чето?

/usr/abills/libexec/rlm_perl.pl  есть

/usr/abills/var/q - нет такой папки

 

Ошибка та же но логины могут быть другие

Відредаговано 2020-01-09 19:44:13 superb

[wantmore 30]

1. Увеличить таймаут обработки запроса радиусом, судя по скрину куча запросов с еррором , не успевает обработать.

2. Почистить логи echo “ “ > имяфайла.log

Відредаговано 2020-01-09 19:49:01 wantmore

[superb 54]

В messages еще это увидел 

 

vpn kernel: pid 85486(radiusd), uid 133:exited on signal 11

[wantmore 30]

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

В messages еще это увидел 

 

vpn kernel: pid 85486(radiusd), uid 133:exited on signal 11

Вентиляторы на сервере все рабочие?

[superb 54]

Только что, wantmore сказав:

Вентиляторы на сервере все рабочие?

Да. Хотя пылью хорошо покрылся. А что думаете перегрев чего-то?

 

Все продолжает работать, не зависает.

[wantmore 30]

https://www.freebsd.org/doc/ru_RU.KOI8-R/books/faq/troubleshoot.html#idp46442360
Да, может быть и перегрев. Надо чистить.

Відредаговано 2020-01-09 20:24:19 wantmore

[masters 126]

У нас такое тоже было. Помогло увеличение количества сессий на мускуле и таймаута радиуса.

[zulu_Radist 856]

В абилсе лучше не хранить логи более 3 месяцев, на 0.5x точно. В среднем авторизация пользователя происходит за 10 запросов, и есть обращения к dv_log.

 

Нужен также тюнинг фрирадиуса

У вас там все по дефолту?

[superb 54]

1 минуту назад, zulu_Radist сказав:

В абилсе лучше не хранить логи более 3 месяцев, на 0.5x точно. В среднем авторизация пользователя происходит за 10 запросов, и есть обращения к dv_log.

 

Нужен также тюнинг фрирадиуса

У вас там все по дефолту?

Да.

[zulu_Radist 856]

Покажите раздел thread pool

[superb 54]

thread pool {
<------>#  Number of servers to start initially --- should be a reasonable
<------>#  ballpark figure.
<------>start_servers = 5

<------>#  Limit on the total number of servers running.
<------>#
<------>#  If this limit is ever reached, clients will be LOCKED OUT, so it
<------>#  should NOT BE SET TOO LOW.  It is intended mainly as a brake to
<------>#  keep a runaway server from taking the system with it as it spirals
<------>#  down...
<------>#
<------>#  You may find that the server is regularly reaching the
<------>#  'max_servers' number of threads, and that increasing
<------>#  'max_servers' doesn't seem to make much difference.
<------>#
<------>#  If this is the case, then the problem is MOST LIKELY that
<------>#  your back-end databases are taking too long to respond, and
<------>#  are preventing the server from responding in a timely manner.
<------>#
<------>#  The solution is NOT do keep increasing the 'max_servers'
<------>#  value, but instead to fix the underlying cause of the
<------>#  problem: slow database, or 'hostname_lookups=yes'.
<------>#
<------>#  For more information, see 'max_request_time', above.
<------>#
<------>max_servers = 128

<------>#  Server-pool size regulation.  Rather than making you guess
<------>#  how many servers you need, FreeRADIUS dynamically adapts to
<------>#  the load it sees, that is, it tries to maintain enough
<------>#  servers to handle the current load, plus a few spare
<------>#  servers to handle transient load spikes.
<------>#
<------>#  It does this by periodically checking how many servers are
<------>#  waiting for a request.  If there are fewer than
<------>#  min_spare_servers, it creates a new spare.  If there are
<------>#  more than max_spare_servers, some of the spares die off.
<------>#  The default values are probably OK for most sites.
<------>#
<------>min_spare_servers = 3
<------>max_spare_servers = 10

<------>#  There may be memory leaks or resource allocation problems with
<------>#  the server.  If so, set this value to 300 or so, so that the
<------>#  resources will be cleaned up periodically.
<------>#
<------>#  This should only be necessary if there are serious bugs in the
<------>#  server which have not yet been fixed.
<------>#
<------>#  '0' is a special value meaning 'infinity', or 'the servers never
<------>#  exit'
<------>max_requests_per_server = 0
}
 

[Ромка 567]

13 часов назад, superb сказал:

Всем привет. Abills 0.55b на Freebsd 7.2.

Привет концу 2kx.

Верните админа, который вам всё делал

Відредаговано 2020-01-10 07:47:35 Ромка

[superb 54]

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

Відредаговано 2020-01-11 12:26:04 superb