Re: [GENERAL] server hardware recommendations (the archives aredead)

From: Jeff Hoffmann <jeff(at)propertykey(dot)com>
To: The Hermit Hacker <scrappy(at)hub(dot)org>
Cc: Adam Rossi <adam(dot)rossi(at)platinumsolutions(dot)com>, pgsql-general(at)postgreSQL(dot)org
Subject: Re: [GENERAL] server hardware recommendations (the archives aredead)
Date: 1999-12-15 15:03:04
Message-ID: 3857ADA8.974ACD6C@propertykey.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

The Hermit Hacker wrote:
>
> On Wed, 15 Dec 1999, Adam Rossi wrote:
>
> > I know this question has been asked before. I have seen it in the archives.
> > Unfortunately the archives are dead right now (any search will yield "no
> > results") and I need to make some decisions.
> >
> > Can anyone give some general recommendations on hardware for a server
> > running Linux (RH6 or 6.1) and PostgreSQL? I estimate that there will be
> > about 2 GIG of data stored in the database initially, but this could grow as
> > high as 5 GIG in the future.
> >
> > Since the db is not multithreaded, I assume that buying a dual processor
> > board and two processors would not be helpful to performance. Like any
>
> actually, if you are going to have concurrent connections to the backend,
> in some circumstances, PostgreSQL will handle multi-processors better then
> others...process one runs on CPU0, process two runs on CPU1, etc...

just to expand on this a little, it really depends on how the OS handles
threads. at worst case, a multithreaded process might be restricted to
running all its threads on a single CPU. i don't know of any OS's that
do that, though. the best case for a multithreaded process (DB) would
be that it could run threads on all processors simultaneously, which
should be nearly equivalent to a multiprocess DB which should (assign
the processes to the CPUs automatically), minus the overhead of each of
the processes. then again, my understanding is that in linux, a thread
is pretty much equivalent to a process anyway, so it would be a wash.
to sum up, SMP & postgres is a good idea.

>
> > database server, a lot of ram will be required for fast operation. I was
> > thinking at a minimum 256 meg of ram. I also want to have the database run
> > on a RAID 5 array for speed and fault tolerance. Any suggestions here for
> > disk type, RAID scheme (software or hardware), controller type, etc.? Any
>
> my preference tends to be software raid...whatever I've ever seen as far
> as hardware raid is concerned has been quite slower then software
> raid...and this is with high-end servers...

i kind of question this, and here's why: i just set up a linux dual
P3/256MB with 4 software raid 5 volumes and even loading data into one
of the databases slows it to a crawl. i've been looking around because
it seems absurd that the machine should slow down so much. i haven't
really found any answers, but i have seen several places which told me
that software raid under linux _isn't_ safe for multiprocessors & no
place has told me for sure that it is. i am running kernel 2.2.12 & i'm
not having any problems with it other than it slowing down to a crawl &
that only happens when i'm loading data. right now i'm guessing the
reason for this is that the raid5 daemon is such a high priority that
it's sucking away all the CPU cycles from everything else to calculate
parity information. like i said, i haven't found a lot of information
about this, so if someone could confirm or explain what's happening, i'd
appreciate it. assuming this is the case, software raid wouldn't be a
big problem if you don't do a lot of heavy writing.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message The Hermit Hacker 1999-12-15 15:27:36 Re: [GENERAL] server hardware recommendations (the archives aredead)
Previous Message The Hermit Hacker 1999-12-15 15:00:01 Mailing List Archives off of Web Site ...