On Thu 26 Jul 2007, Alan DeKok wrote: > Roy Walker wrote: > > Ok chaning the indexes definately made some difference. The database > > load still went off the charts, but the radius logs were much better > > with DB errors connect errors. This still seems horribly slow. > > The problem is that RADIUS servers take less time to do things than an > SQL server needs. So when you hammer the RADIUS server with requests, > the SQL server is getting 5-10x the load. > > > Here is the command I am using to test: /radclient -p 2 -d > > /usr/src/freeradius-server-snapshot-20070725/share -f > > /tmp/radclient-test 1.1.1.10 auth testing123 Where the radclient-test > > file has 5000 client requests seperated by the necessary blank lines. > > FreeRADIUS should really be a little smarter about loading the SQL > server. But it's a very hard problem to solve in a good way. > > i.e. "if SQL server is busy, stop processing the current request, BUT > remember to wake up later to keep processing it." > > The only real solution is to get a bigger machine to handle the > database, OR slow down on the RADIUS traffic.
Yep. there are a few things you can do to limit disastrous situations though. * Turn off any SQL query that you don't need... * Run Accounting and Auth queries through different sql module instances so a flood of auth doesn't kill accounting and visa versa. SQLIPPool can be on a 3rd instance... * Give the radippool table a dedicated disk spindle, or even a dedicated server.. * Likewise for radacct vs all the auth tables.. Auth is read intensive, acct is write intensive.. (You can use different types of RAID even...) * Use radrelay for accounting if possible. Queueing is good for your health.. Given that as far as I can tell you are ONLY testing Auth performance at present, most of these wont help you :-( Cheers -- Peter Nixon http://peternixon.net/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html