On Wed, 2007-09-19 at 15:32 +0200, Bjørn T Johansen wrote:
> > > Well, it isn't really the largest database or the database that
> > > need the most performance... At the moment, the database isn't
> > > larger than 15MB and is growing slowly... It is a webapp that is
> >
> > That'll fit in shared memory. Very fast.
> >
> > Where will it be in a year?
>
> Well, twice as much I guess...
>
> >
> > > using the database and at the most (at the moment) there is about
> > > 12-14 concurrent users and not much data volume...
> >
> > How many users in a year?
>
> It's an internal webapp for a company, so I guess not that much more...
I think, by far, your biggest concern is going to be reliability and
availability. It doesn't sound like you're really worried about
performance.
In that case, you might want to do RAID-1 or RAID-10 (requires at least
4 drives, of course).
Make sure you disable write caching on the individual drives, I think
it's actually enabled by default (weird setting for a RAID controller).
It's safe to enable writeback caching on the battery backed controller,
but I'd advise leaving it off. There's no reason to worry about the
battery if you don't need the performance anyway (however, it will help
your write latency, so you still might consider it).
Get dual power supplies to mitigate the chance of a power supply
failure, even if you don't have two independent circuits.
Oh, and if you're running linux make sure to use a safe setting for
these settings:
vm.oom-kill
vm.overcommit_ratio
vm.overcommit_memory
The default is not very safe for postgresql*. If a java process gets out
of control and eats memory, there's a good chance that it will kill
postgresql before it kills the out-of-control java process :(
Regards,
Jeff Davis
*: I consider this a linux bug: http://lkml.org/lkml/2007/2/9/275