Search Postgresql Archives

Re: RAMFS with Postgres

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 21 Jul 2005, at 17:02, Scott Marlowe wrote:

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?

Isn't that slightly cost prohibitive? Even basic memory has enormously fast access/throughput these days, and for a fraction of the price.

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.

Again with the *money* RAM = Cheap. Disks = Expensive. At least when you look at speed/$. Your right about replicating to disk and to ram though, that is pretty likely to result in horrible problems if you don't keep load down. For some workloads though, I can see it working. As long as the total amount of data doesn't get larger than your RAMFS it could probably survive.


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

              http://archives.postgresql.org

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux