<div dir="ltr">Though you don't have to load a MySQL DB onto a RamDisk. MySQL has the MySQL cluster that loads the entire DB into memory and creates a fault tolerant DB as well. We use that today for an LCR that works well. The newest version of MySQL has stored procs, a very mature replication (it can even do a Cluster to Cluster Replication), triggers, and competes very well with Postgres. But this is a Chevy vs Ford type of discussion.<br>
<br><a href="http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster.html">http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster.html</a><br><br>There are lots of telco's using it as well. I use it a lot for many differnet projects and it keeps up nicely. <br>
<br>--Joe<br><br><br><div class="gmail_quote">On Tue, Aug 12, 2008 at 4:14 PM, Ken Rice <span dir="ltr"><<a href="mailto:krice@suspicious.org">krice@suspicious.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<font size="4"><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;">Actually having evaluated MySQL for large scale environments it works well up to a point... Postgres on the other hand has much more mature replication, store procedures, triggers, a query cacher that insane and no need to use mysql's so called 'hash tables' to get the data loaded into ram (pg does this automagically via its caching mechanism)<br>
<br>
Mix that with table partitioning and you have some fairly crazy numbers<br>
<br>
Real world deployments doing some pretty complex LCR shows that a small cluster (4 boxes) or old dell 2650s are able to sustain > 40K queries/sec (~10% being inserts for CDRs)<br>
<br>
When you get into this scale the real enterprise work that has been done on pgsql starts to show thru... Companies like Greenplum feed a good bit of their core performance tuning back to PgSQL... (for those that are wondering pgsql is bsd licensed so its actually license compatible w/ FreeSwitch say some someone want to look at replacing sqlite with a pgsql engine)<br>
<br>
<br>
<br>
<br>
<hr size="3" width="95%" align="center"><b>From: </b>Darren Schreiber <<a href="mailto:d@d-man.org" target="_blank">d@d-man.org</a>><div class="Ih2E3d"><br>
<b>Reply-To: </b><<a href="mailto:freeswitch-users@lists.freeswitch.org" target="_blank">freeswitch-users@lists.freeswitch.org</a>><br>
</div><b>Date: </b>Tue, 12 Aug 2008 12:35:25 -0700<div><div></div><div class="Wj3C7c"><br>
<b>To: </b><<a href="mailto:freeswitch-users@lists.freeswitch.org" target="_blank">freeswitch-users@lists.freeswitch.org</a>><br>
<b>Subject: </b>Re: [Freeswitch-users] Performance bottleneck<br>
<br>
</div></div></span></font><div><div></div><div class="Wj3C7c"><span style="font-size: 11pt;"><font color="#0000ff"><font face="Arial">I dont know if this makes any sense - it's just an idea.<br>
</font></font><font face="Calibri, Verdana, Helvetica, Arial"> <br>
</font><font color="#0000ff"><font face="Arial">If you're willing to take the hit of running MySQL, I know that it's replication features could potentially be used. You can have the primary MySQL server run in ramdisk and get all the performance benefits of doing so while also writing log files to the ram disk in a seperate area. Those logfiles can, using MySQL's built in replication features, be copied over to a backup server and played backup, giving you both a hot spare as well as a disk based backup.<br>
</font></font><font face="Calibri, Verdana, Helvetica, Arial"> <br>
</font><font color="#0000ff"><font face="Arial">This does three things for you:<br>
1) Gives you backup on disk, while preserving performance in RAM<br>
2) Gives you a live backup that you can quickly shunt things over to if for some reason the primary dies<br>
3) Allows you to handle spikes in volume. MySQL by default will just write to the log files and they can be played back later by the (slower) backup server, so a spike in volume of calls should not cause the server to slow down per say. There is a small risk your data will be lost if there is a failure for whatever is not copied over to the (slower) backup server, but that's unlikely to be that huge a lag (better then nothing).<br>
</font></font><font face="Calibri, Verdana, Helvetica, Arial"> <br>
</font><font color="#0000ff"><font face="Arial">As to whether any of this applies (like why the heck you'd install MySQL on a ramdisk to start), I can't say. but it's a thought...Oh, and you need a lot of RAM ;-)<br>
</font></font><font face="Calibri, Verdana, Helvetica, Arial"><br>
<hr size="3" width="100%" align="center"></font><font face="Tahoma, Verdana, Helvetica, Arial"><b>From:</b> Ken Rice [<a href="mailto:krice@suspicious.org%5D" target="_blank">mailto:krice@suspicious.org]</a> <br>
<b>Sent:</b> Tuesday, August 12, 2008 11:44 AM<br>
<b>To:</b> <a href="mailto:freeswitch-users@lists.freeswitch.org" target="_blank">freeswitch-users@lists.freeswitch.org</a><br>
<b>Subject:</b> Re: [Freeswitch-users] Performance bottleneck<br>
</font><font face="Calibri, Verdana, Helvetica, Arial"><br>
Actually I don't know of any mechanism that will back up the DB... Where sqlite does work well for small to medium installations it only scales to a point... Sqlite does not reuse 'nodes' in the db on an update... It marks them as dead and creates a new entry... While this works ok on smaller tables w/ light to medium updates after a while you have to compress or vacuum the tables... This requires a table level lock with sqlite... FS does have some things built in to handle this, but under load this can cause the switch to appear to hang.<br>
<br>
Switching over to use something like Postgresql (my prefered db) helps out a good bit here, but keep in mind that in doing so you greatly increase the resources required for the db. Also don't forget that pgsql has a similar mechanism on how it handles updates, just don't forget to enable auto-vacuuming on pgsql... That is a discussion for a different list tho<br>
<br>
K<br>
<br>
<br>
<hr size="3" width="95%" align="center"><b>From: </b>Brian West <<a href="mailto:brian@freeswitch.org" target="_blank">brian@freeswitch.org</a>><br>
<b>Reply-To: </b><<a href="mailto:freeswitch-users@lists.freeswitch.org" target="_blank">freeswitch-users@lists.freeswitch.org</a>><br>
<b>Date: </b>Tue, 12 Aug 2008 13:24:40 -0500<br>
<b>To: </b><<a href="mailto:freeswitch-users@lists.freeswitch.org" target="_blank">freeswitch-users@lists.freeswitch.org</a>><br>
<b>Subject: </b>Re: [Freeswitch-users] Performance bottleneck<br>
<br>
Well putting the db in ram does help a bit but it has to keep states of everything going on and do extra work for that... its a heavy task in itself.<br>
<br>
On Aug 12, 2008, at 1:19 PM, Michael Collins wrote:<br>
<br>
</font></span></div></div></font><div><div></div><div class="Wj3C7c"><blockquote><font size="4"><font color="#000080"><font face="Arial"><span style="font-size: 10pt;">That begs the question… is there a mechanism in sqlite or Linux that allows for the RAM drive to be backed up periodically? That would be a cool feature to get documented for those power users like Ken! ;)<br>
<br>
-MC<br>
<br>
</span></font></font></font></blockquote><font size="4"><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;"><br>
<br>
</span></font></font><font face="Helvetica, Verdana, Arial"><span style="font-size: 9pt;">Brian West<br>
<a href="mailto:sip%3Abrian@freeswitch.org" target="_blank">sip:brian@freeswitch.org</a><br>
<br>
<br>
<br>
</span></font><font size="4"><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size: 11pt;"><br>
<br>
<hr size="3" width="95%" align="center"></span></font><font face="Consolas, Courier New, Courier"><span style="font-size: 10pt;">_______________________________________________<br>
Freeswitch-users mailing list<br>
<a href="mailto:Freeswitch-users@lists.freeswitch.org" target="_blank">Freeswitch-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br>
<hr size="3" width="95%" align="center">_______________________________________________<br>
Freeswitch-users mailing list<br>
<a href="mailto:Freeswitch-users@lists.freeswitch.org" target="_blank">Freeswitch-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</span></font></font>
</div></div></div>
<br>_______________________________________________<br>
Freeswitch-users mailing list<br>
<a href="mailto:Freeswitch-users@lists.freeswitch.org">Freeswitch-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br><br></div>