Re: [GENERAL] Hardware optimising
От | Mike Mascari |
---|---|
Тема | Re: [GENERAL] Hardware optimising |
Дата | |
Msg-id | 19990827012959.17972.rocketmail@send205.yahoomail.com обсуждение исходный текст |
Ответы |
Re: [GENERAL] Hardware optimising
(Andy Lewis <alewis@roundnoon.com>)
Re: [GENERAL] Hardware optimising (Bruce Momjian <maillist@candle.pha.pa.us>) |
Список | pgsql-general |
--- 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
В списке pgsql-general по дате отправления: