Re: Sparc v Intel - Mailing list pgsql-general

From Andrew Sullivan
Subject Re: Sparc v Intel
Date
Msg-id 20011205154017.B23863@mail.libertyrms.com
Whole thread Raw
In response to Re: Sparc v Intel  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Sparc v Intel
List pgsql-general
On Mon, Dec 03, 2001 at 11:12:40PM -0500, Tom Lane wrote:
> andrew.clark@sge.net writes:
> > I'm trying to find some hard data comparing PostgreSQL on Intel and Sparc
> > platforms.  Does anyone know where I can find data like this?  Have an view
> > on the subject?  Does a 64 bit architecture make any difference with a
> > small database?  Large databases?  If so how large?
>
> Think I/O, not CPU.  Big-iron Sparc boxes will probably have lots better
> I/O than PC-grade hardware, and that translates directly to database
> performance.

Tom's right about that, but there is one other note that I'd add
about comparing SPARC and non-Solaris Intel.  (Solaris is
sufficiently similar on Intel that the differences might not show up
as dramatically; but if you're willing to shell out for the Solaris
license for Intel, why not just use SPARC?)

If you're used to working with Intel and Linux or BSD, you get some
surprises when you move to SPARC/Solaris.  That's because Solaris is
_unbelievably_ aggresive in buffering files.  We're running Postgres
on some 8-way Sun E4500s with 16 Gig of RAM; and yet with the right
(or wrong, I guess, in that case) combination of file accesses, we
were able to cause paging.  Database performance slowed dramatically,
and yet files that hadn't been accessed for a very long time appeared
still to be buffered.  The kernel buffers are also sufficiently
aggressive that you don't need to be very generous with your shared
memory; I've found that around 1/4 of physical memory is the _most_ I
want to set the shared buffers to, because anything larger runs the
risk that the something will become a candidate for swap.  (Make sure
you have priority paging enabled, too.)

A

--
----
Andrew Sullivan                               87 Mowat Avenue
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M6K 3E3
                                         +1 416 646 3304 x110


pgsql-general by date:

Previous
From: Doug McNaught
Date:
Subject: Re: Can't login/createdb
Next
From: Jan Wieck
Date:
Subject: Re: Use of cursor in PLPGSQL function