Ok, thx for the advice.... :)
BTJ
On Wed, 19 Sep 2007 10:51:57 -0700
Jeff Davis <pgsql@j-davis.com> wrote:
> 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
>
