Re: [GENERAL] Hardware optimising

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
>
>
> ************
>