Re: Is this good spec for a PostgreSQL server?

Поиск
Список
Период
Сортировка
Искать
От
Jeff Davis
Тема
Re: Is this good spec for a PostgreSQL server?
Дата
Msg-id
1190224317.5943.30.camel@dogma.ljc.laika.com
Ответ на
Список
Дерево обсуждения
Is this good spec for a PostgreSQL server? Bjørn T Johansen <btj@havleik.no>
Re: Is this good spec for a PostgreSQL server? tv@fuzzy.cz
Re: Is this good spec for a PostgreSQL server? Bjørn T Johansen <btj@havleik.no>
Re: Is this good spec for a PostgreSQL server? Ron Johnson <ron.l.johnson@cox.net>
Re: Is this good spec for a PostgreSQL server? Bjørn T Johansen <btj@havleik.no>
Re: Is this good spec for a PostgreSQL server? Jeff Davis <pgsql@j-davis.com>
Re: Is this good spec for a PostgreSQL server? Bjørn T Johansen <btj@havleik.no>
Re: Is this good spec for a PostgreSQL server? Ron Johnson <ron.l.johnson@cox.net>
Re: Is this good spec for a PostgreSQL server? Ow Mun Heng <Ow.Mun.Heng@wdc.com>
Re: Is this good spec for a PostgreSQL server? Ron Johnson <ron.l.johnson@cox.net>
Re: Is this good spec for a PostgreSQL server? Ow Mun Heng <Ow.Mun.Heng@wdc.com>
Re: Is this good spec for a PostgreSQL server? Ron Johnson <ron.l.johnson@cox.net>
Porblems migrating a server. David Siebert <david@eclipsecat.com>
Re: Porblems migrating a server. Michael Glaesemann <grzm@seespotcode.net>
Re: Porblems migrating a server. Alvaro Herrera <alvherre@commandprompt.com>
Re: Porblems migrating a server. Michael Glaesemann <grzm@seespotcode.net>
Re: Is this good spec for a PostgreSQL server? "Derek E. Lewis" <dlewis@solnetworks.net>
Re: Is this good spec for a PostgreSQL server? "Scott Marlowe" <scott.marlowe@gmail.com>
Re: Is this good spec for a PostgreSQL server? Benjamin Smith <ben@schoolpathways.com>
Re: Is this good spec for a PostgreSQL server? Ron Johnson <ron.l.johnson@cox.net>
Re: Is this good spec for a PostgreSQL server? Robert Gravsjö <robert@blogg.se>
Re: Is this good spec for a PostgreSQL server? Decibel! <decibel@decibel.org>
Re: Is this good spec for a PostgreSQL server? Gregory Stark <stark@enterprisedb.com>
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 

В списке pgsql-general по дате отправления
От: Scott Ribe
Дата:
Сообщение: Building Windows fat clients
От: MargaretGillon@chromalloy.com
Дата:
FAQ