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@freeswitch.org>
Reply-To: <freeswitch-users@lists.freeswitch.org>
Date: Tue, 12 Aug 2008 13:24:40 -0500
To: <freeswitch-users@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@freeswitch.org
_______________________________________________
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org