[Freeswitch-users] Performance bottleneck

Wed Aug 13 07:27:36 PDT 2008

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.

http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster.html

There are lots of telco's using it as well. I use it a lot for many
differnet projects and it keeps up nicely.

--Joe

On Tue, Aug 12, 2008 at 4:14 PM, Ken Rice <krice at suspicious.org> wrote:

>  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)
>
> Mix that with table partitioning and you have some fairly crazy numbers
>
> 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)
>
> 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)
>
>
>
>
> ------------------------------
> *From: *Darren Schreiber <d at d-man.org>
> *Reply-To: *<freeswitch-users at lists.freeswitch.org>
> *Date: *Tue, 12 Aug 2008 12:35:25 -0700
>
> *To: *<freeswitch-users at lists.freeswitch.org>
> *Subject: *Re: [Freeswitch-users] Performance bottleneck
>
> I dont know if this makes any sense - it's just an idea.
>
> 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.
>
> This does three things for you:
> 1) Gives you backup on disk, while preserving performance in RAM
> 2) Gives you a live backup that you can quickly shunt things over to if for
> some reason the primary dies
> 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).
>
> 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 ;-)
>
> ------------------------------
> *From:* Ken Rice [mailto:krice at suspicious.org] <krice at suspicious.org%5D>
> *Sent:* Tuesday, August 12, 2008 11:44 AM
> *To:* freeswitch-users at lists.freeswitch.org
> *Subject:* Re: [Freeswitch-users] Performance bottleneck
>
> 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.
>
> 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
>
> K
>
>
> ------------------------------
> *From: *Brian West <brian at freeswitch.org>
> *Reply-To: *<freeswitch-users at lists.freeswitch.org>
> *Date: *Tue, 12 Aug 2008 13:24:40 -0500
> *To: *<freeswitch-users at lists.freeswitch.org>
> *Subject: *Re: [Freeswitch-users] Performance bottleneck
>
> 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.
>
> On Aug 12, 2008, at 1:19 PM, Michael Collins wrote:
>
> 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! ;)
>
> -MC
>
>
>
>
> Brian West
> sip:brian at freeswitch.org <sip%3Abrian at freeswitch.org>
>
>
>
>
>
> ------------------------------
> _______________________________________________
> Freeswitch-users mailing list
> Freeswitch-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
> ------------------------------
> _______________________________________________
> Freeswitch-users mailing list
> Freeswitch-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
> _______________________________________________
> Freeswitch-users mailing list
> Freeswitch-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20080813/d6b6e0a6/attachment-0002.html 