Hi Alan,<br><br><div class="gmail_quote">On Tue, Nov 10, 2009 at 8:15 PM, Alan DeKok <span dir="ltr"><<a href="mailto:aland@deployingradius.com" target="_blank">aland@deployingradius.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<br> FreeRADIUS does a mix of selects, inserts and updates for accounting.<br>
 It may be that the DB can only handle 1000 transactions/s with that mix.<br>
<br>
  See also "sqltrace" config in sql.conf.  You can try the following tests:<br>
<br>
- start off with a clean (i.e. empty) DB<br>
- enable sqltrace<br>
- run 10's of 1000's of packets through the server<br>
- wipe the DB<br>
- use a command-line SQL client to re-play SQL queries from the sqltrace<br>
file
 <br></blockquote></div><br><br>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.<br>

<br>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 ?<br><br>Thanks<br><br><br>Dinh<br>