--- Andy Lewis <[EMAIL PROTECTED]> 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
([EMAIL PROTECTED])
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
************
