Sparc v Intel

Started by Nonameover 24 years ago8 messagesgeneral
Jump to latest
#1Noname
andrew.clark@sge.net

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?

Andrew Clark
90East (Asia Pacific) Pty Ltd
Canberra, Australia

02 6272 3700 (switch)
02 6272 3010 (facsimile)

andrew.clark@sge.net
www.90East.com

******************************************************************************

NOTICE
If you are not the intended recipient of this e-mail, be advised that
You have received it in error and that any use, copying,
circulation, forwarding, printing or publication are forbidden, as is
its disclosure. If you have received this message in error, please
notify the sender immediately and delete it from your in-box.
Thank you.

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Noname (#1)
Re: Sparc v Intel

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.

Which is not to say that you can't buy big-iron platforms with Intel
CPUs in 'em. But they're not consumer PCs. Be careful to compare
apples to apples.

As far as 32bit vs 64bit, my feeling is that the only immediate benefit
of 64bit is that you could load the thing with more than 4GB of RAM and
have *lots* of kernel disk buffers. This could be a serious win if your
database is large enough that the active page set exceeds 4GB.

Further out, we've speculated off and on about converting int8 and
float8 to pass-by-value datatypes on machines where Datum is 8 bytes.
That should make for a nice performance improvement on operations using
those datatypes. But it's not done yet and the actual benefit is hard
to guess.

regards, tom lane

#3Andrew Sullivan
andrew@libertyrms.info
In reply to: Tom Lane (#2)
Re: 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
#4Robert J. Sanford, Jr.
rsanford@nolimitsystems.com
In reply to: Andrew Sullivan (#3)
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

Show quoted text

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

#5Doug McNaught
doug@wireboard.com
In reply to: Robert J. Sanford, Jr. (#4)
Re: Sparc v Intel

"Robert J. Sanford, Jr." <rsanford@nolimitsystems.com> writes:

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

Good article. I wondered, and wasn't able to find out from the
article or the site, what database they're using. Anybody know?

-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863

#6Steve Wolfe
steve@iboats.com
In reply to: Robert J. Sanford, Jr. (#4)
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

You'll also notice that when they were mentioned on slashdot, it brought
their entire site to a complete stop - as in "server unreachable" for
quite a while. Having a site run slowly after it's been slashdotted isn't
uncommon, but their server setup that they were so proud of was completely
overwhelmed on it's first day. : )

In my opinion, they just wanted to have a "hey, we know about servers!"
page because some of the other hardware review places have put up similar
stories. And to be honest, none of those have had setups that truly
impressed me, either.

steve

#7Robert J. Sanford, Jr.
rsanford@nolimitsystems.com
In reply to: Doug McNaught (#5)
Re: Sparc v Intel

SPECMine???

http://www.aceshardware.com/read_news.jsp?id=55000381

rjsjr

Show quoted text

-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org]On Behalf Of Doug McNaught
Sent: Wednesday, December 05, 2001 4:36 PM
To: Robert J. Sanford, Jr.
Cc: PostgreSQL general list
Subject: Re: [GENERAL] Sparc v Intel

"Robert J. Sanford, Jr." <rsanford@nolimitsystems.com> writes:

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

Good article. I wondered, and wasn't able to find out from the
article or the site, what database they're using. Anybody know?

-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

#8Gregory Wood
gregw@com-stock.com
In reply to: Robert J. Sanford, Jr. (#7)
Re: Sparc v Intel

SPECMine is the application... the database is a "custom in-memory
database".

http://www.aceshardware.com/read.jsp?id=45000252

Greg

----- Original Message -----
From: "Robert J. Sanford, Jr." <rsanford@nolimitsystems.com>
To: "PostgreSQL general list" <pgsql-general@postgresql.org>
Sent: Wednesday, December 05, 2001 6:34 PM
Subject: Re: [GENERAL] Sparc v Intel

SPECMine???

http://www.aceshardware.com/read_news.jsp?id=55000381

rjsjr

-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org]On Behalf Of Doug McNaught
Sent: Wednesday, December 05, 2001 4:36 PM
To: Robert J. Sanford, Jr.
Cc: PostgreSQL general list
Subject: Re: [GENERAL] Sparc v Intel

"Robert J. Sanford, Jr." <rsanford@nolimitsystems.com> writes:

aces hardware recently upgraded their architecture to a sun blade.

they

have an article talking about why they chose the hardware that they

did

Show quoted text

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

Good article. I wondered, and wasn't able to find out from the
article or the site, what database they're using. Anybody know?

-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)