Hi Alan,<br><br>I have attached a graph created by Munin that shows how MySQL works under FreeRadius load test<br><br><a href="http://img4.imageshack.us/img4/7204/mysqlqueriesday.png">http://img4.imageshack.us/img4/7204/mysqlqueriesday.png</a><br>
<br>This test was conducted last night. I used 2 16-core Dell servers, FastEthernet 100Mb to run 2 test clients to test 2 Radius servers. Each client created 100 concurrent threads to simulate 100 concurrent users and send 10 000 000 start request and 10 000 000 stop each thread. Radius server and MySQL are installed in a 16-core Dell server too. I expect that the test can take several hours in the night. At some point of times in the very early this morning, Munin found that there was very high load in our MySQL server: 11 000 INSERT query/s and 11 000 DELETE query/s. It was because one of Radius server crashed and all the traffic was forwarded to the rest by the load balancer. <br>
<br>It means that MySQL is not slow. There may be a bug in FreeRadius that makes it impossible to work in very high load environment: thread deadlock or kind of race condition??? Have someone got into this problem?<br><br>
Thanks<br><br>Dinh<br><br><div class="gmail_quote">On Tue, Nov 10, 2009 at 10:50 PM, Dinh Pham Cong <span dir="ltr"><<a href="mailto:dinhpc@vega.com.vn">dinhpc@vega.com.vn</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;">
Hi Alan,<div class="im"><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></div>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><font color="#888888"><br><br>Dinh<br>
</font></blockquote></div><br>