Re: Sparc v Intel

aces hardware recently upgraded their architecture to a sun blade. they
have an article talking about why they chose the hardware that they did
as well as pointing out some of the application design decisions they
made to improve the performance of the site. you can read about it at:
   http://www.aceshardware.com/read.jsp?id=45000240

rjsjr

> -----Original Message-----
> From: pgsql-general-owner@postgresql.org
> [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Andrew Sullivan
> Sent: Wednesday, December 05, 2001 2:40 PM
> To: PostgreSQL general list
> Subject: Re: [GENERAL] Sparc v Intel
>
>
> 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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>