On Sun, 18 Jul 2004, jesk wrote:
> > 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.
What's the time difference between sending the accounting-request and receiving
the accounting-response.
> the 2 radiuservers doesnt have any problems in processing accounting
> requests of
> 70 NASes.
Meaaning theat you don't see any radius timeouts in the NASes?
There are two quite different problems which can cause the problem you are
facing:
1. The radius server (which is accepting the data) is somewhat slow, so
accounting requests take a while to be acknowledged and radrelay free slots are
consumed. Enlarging the number of slots can help somewhat in this situation.
2. The detail file grows faster than radrelay can send the data out since it
serializes transmission. Again enlarging the number of slots can help so that
radrelay has a larger data buffer to send.
If your two radius servers (A sending,B accepting data) are identical and you
only use radrelay to keep them synchronized, and you don't see any timeouts on
your NASes then i 'll accept that radrelay is not fast enough and is the
bottleneck.
> 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.
The process is serialized yes, but more slots will allow you to have more
outstanding requests. This can help only if radrelay is using up it's slots (in
other words when the accepting radius server is slow).
> 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
>
--
Kostas Kalevras Network Operations Center
[EMAIL PROTECTED] National Technical University of Athens, Greece
Work Phone: +30 210 7721861
'Go back to the shadow' Gandalf
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
