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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
