Re: Dream Server? - Mailing list pgsql-general

From Medi Montaseri
Subject Re: Dream Server?
Date
Msg-id 3C61D9C9.6266D2EB@cybershell.com
Whole thread Raw
In response to Dream Server?  ("Gavin M. Roy" <gmr@justsportsusa.com>)
List pgsql-general
Perhaps we should think wide not tall. As the pontiac commercial says, wider
is
better. Build a distributed database. Increasing height of a box does not
scale.
Amdahl proved it.

Perhaps someone can help with some links, it have seen references to it on
ha-linux groups.

Steve Wolfe wrote:

> > I'm currently running a 4 Gig 11 million row database and am looking
> > to build a "dream server" for it.   I am currently running a dual p3
> > 1GHz system with 10k rpm scsi drives and 4 gigs of ram (which I have
> > configured pgsql to use all of) and I'm concerned about performance
> > once the db doubles in size, which should be in 6 mos to a year at
> > the latest.  First off, If money was no concern, what would you buy
> > as the ultimate postgresql server running linux?
>
>   I don't know if Linux runs on the new version of the Sun Starfires, does
> it?
>
> > Second off, on a
> > more technical note, does pgsql take advantage of multiple
> > processors.
>
>   If you are running multiple connections, then yes, it does.  But having
> an extra CPU around to handle kernel code, disk activity, network
> activity, etc. does help even for a single connection.
>
> > If I had a 8 way 800 MHz Xeon would the machine blow
> > away a 2GHz P4?  How much is CPU a factor compared to memory?
>
>    Both CPU and memory have to be taken into account.  It does you no good
> to have a 10 GHz chip if your memory subsystem can't provide the data to
> feed the chip, and likewise, having 10 GB/sec throughput from your memory
> system does no good if you are running a 386!  If you're using extremely
> large tables (which it sounds like you will be), then memory throughput is
> a very critical factor.
>
>   As for the 8-Xeon to 2-P4, in total throughput, yes, the Xeon should
> blow away the P4, assuming that you were talking about overall throughput
> with multiple connections, and the 8-way machine had a memory subsystem
> that was up to the task.  If you're talking about a single query on a
> single connection, then the P4 may very well beat the Xeon.  Ideally, your
> SMP machine should require you to add DIMMS in groups equal to the number
> of your processors - in this case, 8 DIMMS at a time.  Otherwise, you
> simply can't give each chip the full bandwidth.  One interesting solution
> would be to interleave 4 banks of DDR Ram to feed 8 Xeons, but I doubt
> we'll ever see that in production.
>
> > Disk
> > speed?  I want to be able to do large volume selects on tables with
> > more than 5 million rows and not have the server blink at other
> > requests put in at the same time.
>
>   If you have enough RAM to keep the entire database in disk cache, then
> disk speed becomes much less of a factor, if you turn of fsync().  Like
> I've said plenty of times before (and probably bored everyone to tears),
> the lights on our DB machine only blink *occasionally*, even when the
> machine is literally being slammed with database activity.  A hardware
> RAID card with cache on the board and some moderately-decent drives can
> give you a VERY fast, responsive disk subsystem.
>
>   In a day or two, I'll be getting the parts to build a dual Athlon MP
> 1800+ machine, and I'm planning on putting PG on it and testing it against
> our 4x700 MHz Xeon machine, to see how it fares.  Once I do, I'm planning
> on making a full report to the list.  If anyone has a certain PG benchmark
> that they'd like me to run, let me know.
>
> steve
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

--
-------------------------------------------------------------------------
Medi Montaseri                               medi@CyberShell.com
Unix Distributed Systems Engineer            HTTP://www.CyberShell.com
CyberShell Engineering
-------------------------------------------------------------------------




pgsql-general by date:

Previous
From: Lamar Owen
Date:
Subject: Re: [HACKERS] PostgreSQL v7.2 Final Release
Next
From: Patrick Dunford
Date:
Subject: Re: Server does not reply to Alter Table