Re: [GENERAL] server hardware recommendations (the archives aredead) - Mailing list pgsql-general
From | Jeff Hoffmann |
---|---|
Subject | Re: [GENERAL] server hardware recommendations (the archives aredead) |
Date | |
Msg-id | 3857ADA8.974ACD6C@propertykey.com Whole thread Raw |
In response to | Re: [GENERAL] server hardware recommendations (the archives are dead) (The Hermit Hacker <scrappy@hub.org>) |
Responses |
Re: [GENERAL] server hardware recommendations (the archives aredead)
(The Hermit Hacker <scrappy@hub.org>)
|
List | 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.
pgsql-general by date: