> Are you sure that the radius server you are relaying the logs to is
processing
> them ok? Do you get responses fast enough?
> Currently radrelay can have up to 64 requests pending which is quite fine.
If
> that is not enough you can change the NR_SLOTS variable in
src/main/radrelay.c
> and run make radrelay.
>
define fast enough.
the 2 radiuservers doesnt have any problems in processing accounting
requests of
70 NASes. but all NASes are sending ALIVE packets for every connection all
10 minutes in due to marking sessions as closed if sessiontime is not
updated within
30 minutes. the radacct table is indexed and in my oppinion fast enough
otherwise i
would get many erros or problems due to live request repeations.
the mysqldatabase is configured with a moderate thread_cache_size and the
wait_timeout
is very high.
radiusd is configured with:
cleanup_delay = 10
max_requests = 71680
start_servers = 80
max_servers = 384
start_servers = 128
min_spare_servers = 25
max_spare_servers = 100
max_requests_per_server = 0
rlm_sql:
num_sql_socks = 256
os is freebsd5.2.1 running on i386/pIII with 1ghz and 1gb on ram.
the load on the mysqlthreads trends against zero.
radiusd get not more on load than 6-8%
23228 freeradius 76 0 169M 8056K select 2:29 2.34% 2.34%
radiusd
the NR_SLOTS variable will give me more slots but wont accelrate the
accounting-process i think.
for testing purpose i have splitted the detail-combined into 3 files for
every acct-status-type
( detailfile = ${radacctdir}/%{Acct-Status-Type}-detail-combined )
and was running 3 instances of radrelay to proceed them several
simultaneously, this environment
is running fine and confident of a fast respone time of the destination
freeradius server. so the problem
cant be freeradius or the backend.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
