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/