Re: RAMFS with Postgres

Hi,

My application is database intensive. I am using 4 processes since I have 4
processeors on my box. There are times when all the 4 processes write to the
database at the same time and times when all of them will read all at once.
The database is definitely not read only. Out of the entire database, there
are a few tables which are accessed most of the times and they are the ones
which seem to be the bottleneck. I am trying to get as much performance
improvement as possible by putting some of these tables in RAM so that they
dont have to be read to/written from hard disk as they will be directly
available in RAM. Here's where slony comes into picture, since we'll have to
mainatin a copy of the database somewhere before running our application
(everything in RAM will be lost if there's a power failure or anything else
goes wrong).

My concern is how good Slony is?
How much time does it take to replicate database? If the time taken to
replicate is much more then the perf. improvement we are getting by putting
tables in memory, then there's no point in going in for such a solution. Do
I have an alternative?

Regards,
Vinita Bansal

>From: Marco Colombo <pgsql@esiway.net>
>To: vinita bansal <sagivini@hotmail.com>
>CC: pgsql-general@postgresql.org
>Subject: Re: RAMFS with Postgres
>Date: Wed, 20 Jul 2005 12:08:49 +0200
>
>On Tue, 2005-07-19 at 16:45 +0000, vinita bansal wrote:
> > Hi,
> >
> > I am  trying RAMFS solution with Postgres wherein I am pushing the most
> > heavily used tables in RAM.
>
>Why? I mean, what problem are you trying to solve?
>
> > I have 32GB RAM on a 64 bit opteron machine. My database size is 40GB. I
> > think Linux allows max. of 16GB (half of available RAM) to be used
>directly
> > to push tables to it.
> >
> > I am concerned about reliabilty here (what if there is a power failure).
> > What are the things that need to be considered and what all can be done
>to
> > ensure that there is no data loss in case something goes wrong. What
>steps
> > must be taken to ensure data recovery. I am planning to use Slony
> > replication to replicate my database to a diff node so that incase
>something
> > goes wrong, I can restore it from replication node and start my runs on
>that
> > data again. The only problem here is that I need to run engines from
> > beginning. Is there any other way of doing the same thing or such a
>thing is
> > good enough given the fact that a failure like this happens very rarely.
>The
> > most imp. thing for me is the **data** which should not be lost under
>any
> > circumstances.
>
>Then don't use RAMFS. Slony may be a good idea, but it's hard to tell if
>you don't provide more info.
>
>What is the database used for?
>- heavy long running, CPU-based, read only queries?
>- many simple queries but over the whole dataset (thus I/O based)?
>- many INSERTs/UPDATEs?
>
>Is the database accessed by many concurrent users? How many of them are
>mostly read-only and how many perform writes?
>
>Each problem in each scenario may have a different solution...
>
> > Has anyone used Slony replication before. How good is it. Is there
>anything
> > else available which is better then Slony Replication?
>
>"better" is meaningless w/o a context. There are tasks in which Slony
>may the best tool in the world, and others that require a totally
>different approach. First you have to define what your problem is, and
>why the obvious solution (a normal PostGreSQL server, with a standard
>filesystem) does not work/fit. Then you choose a solution.
>
> >
> > Regards,
> > Vinita Bansal
>
>.TM.
>--
>       ____/  ____/   /
>      /      /       /                   Marco Colombo
>     ___/  ___  /   /                  Technical Manager
>    /          /   /                      ESI s.r.l.
>  _____/ _____/  _/                      Colombo@ESI.it
>

_________________________________________________________________
Logon to MSN Games http://www.msngamez.com/in/gamezone/ Enjoy unlimited
action