Slow Accounting-Database - workaround?
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: 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? Thanks, Oliver - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Slow Accounting-Database - workaround?
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
Re: Slow Accounting-Database - workaround?
Kostas Kalevras wrote: 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. Thank you, I will see if we can use it. Compiling the 20050510-Snapshot of freeradius 1.1.0 under Debian(Sarge) I had a problem with make install. But I think it is known, and I solved it by removing the source-code of the module rlm_eap. make install: ... *** Warning: Linking the shared library rlm_eap_peap.la against the loadable module^M *** rlm_eap_tls.so is not portable!^M ^M *** Warning: Linking the shared library rlm_eap_peap.la against the loadable module^M *** libeap.so is not portable!^M ... Nice, that the new radzap ist working! Bye, Oliver - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
