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@xxxxxxxxxx>
To: vinita bansal <sagivini@xxxxxxxxxxx>
CC: pgsql-general@xxxxxxxxxxxxxx
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@xxxxxx
_________________________________________________________________
Logon to MSN Games http://www.msngamez.com/in/gamezone/ Enjoy unlimited
action
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
