Re: Hardware estimation - Mailing list pgsql-general

From Lamar Owen
Subject Re: Hardware estimation
Date
Msg-id 200211072024.04780.lamar.owen@wgcr.org
Whole thread Raw
In response to Re: Hardware estimation  ("scott.marlowe" <scott.marlowe@ihs.com>)
List pgsql-general
On Thursday 07 November 2002 19:31, scott.marlowe wrote:
> Flashback.  Five years ago when I first started working here (ihs), I
> built our PDC/BDC pair on a Supermicro Dual PPro-200 motherboard.  Having
> long since moved on to web development and such, I never expected to see
> them again.

I have three of them.  P6DNE.  They are wonderful.

> So, even a 2 way 400 MHz box (say a two year old USparc) with 2Megs or
> more of L2/3 cache, that can hold say 8 gigs of ram and let postgresql use
> most of it for buffer is likely a better choice than a quad Xeon 1.5GHz,
> if it can hold more of the data you're accessing in memory and keep you
> away from disk IO.  This is especially true if you're gonna have a high
> simo load.

FWIW, I ran the regression test 'benchmark' in parallel mode on a few
machines.  I was mildly surprized at the results.  My Athlon 1.2 notebook
runs the set in about 1.5 minutes.  A Pentium II 400 at work, with a _fast_
HD, runs them in 1.75 minutes.  My Sun Ultra 5 with a moderately fast IDE HD
and a 333 UltraSPARC IIi w/ 768MB RAM runs them in 2.5 minutes.  An old
SPARCstation 5/110 with a relatively quick 4.3GB Fujitsu SCSI drive and 160MB
RAM takes _23.5_ minutes.  An Ultra 30/248 with 128MB and the same Fujitsu
drive takes 5 minutes.  A larger Sun box would have increasingly better
times, of course, due to the SMP support.  OS in all cases was Red Hat Linux
7.3 or its SPARC twin, Aurora 0.42.

The U5 has 2MB ecache, the U30 has 1MB ecache. (ecache = L2 in PC jargon).
One must note, however, that the U5 has much slower RAM than the Athlon
notebook or the PII 400, which both use PC100 SDRAM -- the U5 uses 60ns EDO.
But it still holds its own.

I need to rerun them on my dual PPro 200/512 system, once I get it running
again.

The disk I/O is the killer.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

pgsql-general by date:

Previous
From: "scott.marlowe"
Date:
Subject: Re: Hardware estimation
Next
From: "Robert John Shepherd"
Date:
Subject: Restoring a db dump with tsearch fields fails