On Thu, 2005-07-21 at 02:43, vinita bansal wrote:
> 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?
My feeling is that you may be going about this the wrong way. Most
likely the issue so far has been I/O contention. Have you tested your
application using a fast, battery backed caching RAID controller on top
of, say, a 10 disk RAID 1+0 array? Or even RAID 0 with another machine
as the slony slave?
Slony, by the way, is quite capable, but using a RAMFS master and a Disk
drive based slave is kind of a recipe for disaster in ANY replication
system under heavy load, since it is quite possible that the master
could get very far ahead of the slave, since Slony is asynchronous
replication. At some point you could have more data waiting to be
replicated than your ramfs can hold and have some problems.
If a built in RAID controller with battery backed caching isn't enough,
you might want to look at a large, external storage array then. many
hosting centers offer these as a standard part of their package, so
rather than buying one, you might want to just rent one, so to speak.
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
