<div>I have interim accounting value 10 minutes and IP lease time is 30 minutes.<br clear="all"></div><br><br><div class="gmail_quote">2012/1/12 Phil Mayers <span dir="ltr"><<a href="mailto:p.mayers@imperial.ac.uk">p.mayers@imperial.ac.uk</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 01/12/2012 11:59 AM, Fajar A. Nugraha wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That's why having a dba is important. If you can't do it yourself,<br>
hire one. Or learn to be one. Depending on your deployment scale, the<br>
cost is justifiable. Seriously.<br>
</blockquote>
<br></div>
Agreed, this is the key. SQL optimisation is a specialist task, and if you lack the specialist skills, you need to acquire them.<br>
<br>
However, I'm quite surprised that you're having problems with 25k subscribers; that's not a large table.<br>
<br>
What is the query rate? Do you have very low interim accounting values perhaps, meaning you're extending the IP "lease" times too frequently?<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So in short, for now:<br>
- revert your changes<br>
- try changing the engine to innodb<br>
- if it's still too slow, hire a dba, and/or be prepared to implement<br>
mysql cluster (or something like clustrix)<br>
<br>
</blockquote>
<br></div>
- use postgres<br>
<br>
;o)<br>
<br>
In all seriousness, It's worth noting that postgres does have the advantage that "select ... for update" uses row-level locking, not table level. So, you can allocate IPs without fear of duplication, transactionally.<div class="HOEnZb">
<div class="h5"><br>
<br>
-<br>
List info/subscribe/unsubscribe? See <a href="http://www.freeradius.org/list/users.html" target="_blank">http://www.freeradius.org/list/users.html</a><br>
</div></div></blockquote></div><br>