On Tue, 10 May 2005, oz wrote:
Hello,
our Accounting-SQL-Database became slower, so often radius-packets are dropped and and the NAS falls back to the secondary radius-server. Though the postgres database is indexed, there are often response-times between 1 - 3 secs and we cannot change it for the moment.
To speed up things a little, I tried to change from single- to multi-threaded radius mode, but the problems even get worse. Only a few minutes after radiusd start, the maximum number of threads (= 256) is reached, caused by "Unresponsive childs", which might be slow database answers:
That makes sense. Instead of serializing writes to a *slow* database you are performing them in parallel which will be even worse.
radius.log:
...
Tue May 10 10:59:48 2005 : Error: WARNING: Unresponsive child (id 1015871) for request 71
Tue May 10 10:59:48 2005 : Info: The maximum number of threads (256) are active, cannot spawn new thread to handle request
...
Is there any chance to use freeradius-1.0.2 with a *slow* SQL-Database?
I read something about "radsqlrelay" in the 1.1.0 snapshot - can that be used to form some kind of "buffer queue" between the radiusd and the slow accounting database?
Or will radsqlrelay step into the same timing-problem as the single- or multi-threaded radiusd?
Yes use radsqlrelay. It's in cvs. radsqlrelay will be used in combination with a detail file for buffering and can handle sql database slow downs/failures. Bear in mind though that if your sql database cannot handle the accounting rate no buffering will do you any good in the long run.
Thanks, Oliver
- 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
