Skip site navigation (1) Skip section navigation (2)

Best setup for RAM drive

From: Chris Sutton <chris(at)smoothcorp(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Best setup for RAM drive
Date: 2003-03-04 15:03:59
Message-ID: Pine.LNX.4.44.0303040649290.9814-100000@taurus.smoothcorp.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Hello,

I need some insight on the best way to use a RAM drive in a Postgresql 
installation.  Here is our situation and current setup:

Postgresql 7.2.1
Dual PIII 800
RAID 5 SCSI disks
Platypus 8GB PCI QikDrive (the RAM drive).  http://www.platypus.net

The Platypus RAM drive is a PCI card with 8GB of ram onboard with an 
external power supply so if the main power to the server goes off, the RAM 
is still powered, so it's persistent between reboots.

Currently the disk size of our database is 3.2GB, so we put the whole 
pgsql directory on the RAM drive.  Current preformance is very 
snappy with the bottleneck being the CPUs.  

The concern of course is if something happends to the RAM drive we are 
S.O.L. and have to go to the last backup (pg_dump happens each night).

The other concern is if the disk size of the database grows past or near 
8gb, we would either have to get a bigger RAM drive or somehow split 
things betten SCSI and RAM drive.

I don't quite grasp the full inner workings of Postgresql, but 
for those of you who obviously do, is there a better way of setting things 
up where you could still use the RAM drive for portions of the pgsql 
directory structure while putting the rest on disk where it's safer?

Should we just put pgsql/data/pg_xlog on the RAM drive?

Also, in the very near future we will be upgrading to another server, 
pg7.3.2 with dual P4 2.4 xenon's.  The RAM drive will go into this new 
server.

Any suggestions?

Thanks

Chris



Responses

pgsql-hackers by date

Next:From: Rod TaylorDate: 2003-03-04 16:16:20
Subject: Re: [PATCHES] ALTER SEQUENCE
Previous:From: Brandon Craig RhodesDate: 2003-03-04 04:01:11
Subject: Re: bug? rules fail to cascade after NOT IN

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group