Thread: Re: [GENERAL] Hardware optimising
--- Andy Lewis <alewis@roundnoon.com> wrote: > What scheduler are we speaking of here? > > Andy > > On Thu, 26 Aug 1999, Bruce Momjian wrote: > > > > as for the processor, this will see an increase, > of course. note, > > > however, that since PostgreSQL is _not_ > multithreaded, that it will run > > > only on one of the processors. (i'm about to > assume you are using linux > > > here... 'scuse me if i'm wrong) however, the > good news is that you can > > > encourage linux (through the scheduler) to run > postgres on one of the > > > processors and everything else on the other one. > this should give the > > > database its own processor more oft than not. > things may still drift, > > > etc... but it will be better this way.... > > > > Different backends can use different CPU's, no > problem. > > > > -- > > Bruce Momjian Bruce, of course, is, as always, absolutely correct. Each connection to the backend starts a postgres process which will be assigned to either CPU by Linux. I have read (either somewhere in the SMP FAQ or some mailing list) that there are utilities forthcoming (this was awhile ago) to assign a process to a specific CPU. There are several advantages to having a multithreaded backend instead of a multitasking backend since connections would be faster, no need for shared memory segments, etc., but use of multiple processors is not exclusive to multithreading applications. Any application which forks() or execs() another can take advantage of multiple processors. And there are disadvantages to multithreading too as pointed out in previous threads (no pun intended), such as stability of the running process if one of its threads dies abnormally. With regard to the original post, I again, agree fully with Bruce - SCSI first. And spend an extra couple hundred to get the 80MBs variety, dual channel controllers; its worth it. Hopefully one would also be able to optimize the disk configuration as well. We run RedHat Linux 2.0.36 on a Dual 450Mhz deskside server with 256M of RAM. The only regret I have is we didn't get the 80MBs (we got 40MBs) controller and (6) 4 Gig hard drives. Instead we got (2) 9 Gig drives. This forces us to only run RAID 1. For only a few hundred more, we could have run RAID 0+1 on dual channels (with each mirror on the other channel). We also put the database on the second innermost partition, with the outer being swap. Finally, if you are using Linux and choose to go the SMP route, I highly recommend the newer 2.2 kernels. We saw dramatic improvement in speed over 2.0.36 vs. 2.2.x in our testing environment. In fact, to enable SMP on a 2.0.36 kernel, you must modify the top-level Makefile for the kernel and rebuild. Anyways, Hope that helps, Mike Mascari (mascarim@yahoo.com) P.S. From previous posts, I'm starting to think that there is a VAST misconception that a single-threaded database engine (which is what Oracle was until some version 7 releases, I believe, called Oracle MTS appeared) can only handle ONE query at a time, and does not exec() a child process for each connection. Someone ought to start the propoganda of claiming multi-threaded DBMS as "single process" servers. __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
Thanks for the info! Much appreciated! Andy On Thu, 26 Aug 1999, Mike Mascari wrote: > --- Andy Lewis <alewis@roundnoon.com> wrote: > > What scheduler are we speaking of here? > > > > Andy > > > > On Thu, 26 Aug 1999, Bruce Momjian wrote: > > > > > > as for the processor, this will see an increase, > > of course. note, > > > > however, that since PostgreSQL is _not_ > > multithreaded, that it will run > > > > only on one of the processors. (i'm about to > > assume you are using linux > > > > here... 'scuse me if i'm wrong) however, the > > good news is that you can > > > > encourage linux (through the scheduler) to run > > postgres on one of the > > > > processors and everything else on the other one. > > this should give the > > > > database its own processor more oft than not. > > things may still drift, > > > > etc... but it will be better this way.... > > > > > > Different backends can use different CPU's, no > > problem. > > > > > > -- > > > Bruce Momjian > > Bruce, of course, is, as always, absolutely correct. > Each connection to the backend starts a postgres > process which will be assigned to either CPU by > Linux. I have read (either somewhere in the SMP FAQ > or some mailing list) that there are utilities > forthcoming (this was awhile ago) to assign a process > to a specific CPU. There are several advantages to > having a multithreaded backend instead of a > multitasking backend since connections would be > faster, no need for shared memory segments, etc., > but use of multiple processors is not exclusive to > multithreading applications. Any application which > forks() or execs() another can take advantage of > multiple processors. And there are disadvantages to > multithreading too as pointed out in > previous threads (no pun intended), such as stability > of the running process if one of its threads dies > abnormally. > > With regard to the original post, I again, agree > fully with Bruce - SCSI first. And spend an extra > couple hundred to get the 80MBs variety, dual channel > controllers; its worth it. Hopefully one would also > be able to optimize the disk configuration as well. > We run RedHat Linux 2.0.36 on a Dual 450Mhz deskside > server with 256M of RAM. The only regret I have is > we didn't get the 80MBs (we got 40MBs) controller > and (6) 4 Gig hard drives. Instead we got (2) 9 Gig > drives. This forces us to only run RAID 1. > For only a few hundred more, we could have run > RAID 0+1 on dual channels (with each mirror on the > other channel). We also put the database on the second > innermost partition, with the outer being swap. > > Finally, if you are using Linux and choose to go > the SMP route, I highly recommend the newer 2.2 > kernels. We saw dramatic improvement in speed over > 2.0.36 vs. 2.2.x in our testing environment. In fact, > to enable SMP on a 2.0.36 kernel, you must modify the > top-level Makefile for the kernel and rebuild. > > Anyways, > > Hope that helps, > > Mike Mascari > (mascarim@yahoo.com) > > P.S. From previous posts, I'm starting to think that > there is a VAST misconception that a single-threaded > database engine (which is what Oracle was until some > version 7 releases, I believe, called Oracle MTS > appeared) can only handle ONE query at a time, and > does > not exec() a child process for each connection. > Someone ought to start the propoganda of claiming > multi-threaded DBMS as "single process" servers. > > __________________________________________________ > Do You Yahoo!? > Bid and sell for free at http://auctions.yahoo.com > > > ************ >
> P.S. From previous posts, I'm starting to think that > there is a VAST misconception that a single-threaded > database engine (which is what Oracle was until some > version 7 releases, I believe, called Oracle MTS > appeared) can only handle ONE query at a time, and > does > not exec() a child process for each connection. > Someone ought to start the propoganda of claiming > multi-threaded DBMS as "single process" servers. Yes, I am totally unsure how this gets confused by people. I am going to put it int the FAQ. Yes, and I agree that most multi-threaded DBMS are "single process", which can't make use if multiple cpus, except on some very special OS's that allow threads to move between cpus, sometimes called kernel threads, I think, but I am not sure on that. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026