Hi Alan,

On Tue, Nov 10, 2009 at 8:15 PM, Alan DeKok <aland@deployingradius.com> wrote:

 FreeRADIUS does a mix of selects, inserts and updates for accounting.
 It may be that the DB can only handle 1000 transactions/s with that mix.

 See also "sqltrace" config in sql.conf.  You can try the following tests:

- start off with a clean (i.e. empty) DB
- enable sqltrace
- run 10's of 1000's of packets through the server
- wipe the DB
- use a command-line SQL client to re-play SQL queries from the sqltrace
file


I have enabled sqltrace and found that for accounting purpose, there was only a single query made into MySQL for accounting stop or start: An insert for start and a delete for stop. For single INSERT and/or DELETE I have used mysqlslap for stress testing and found that MYSQL can handle 6000 - 8700 qps for 2000 concurrent clients. Therefore I double that MySQL is not a bottleneck. There might be something wrong with FreeRadius that made it not scalable when the load is high. When FreeRadius crashed there were only 1200 - 1400 radiusd threads as Munin recorded it.

The way it crashed is strange too. No fatal error in radius.log. There is a single kernel log found in /var/log/messages. Is it stable in 64 bit OS and SMP ?

Thanks


Dinh