Thread: Sparc v Intel
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.
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
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
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) >
"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
> 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
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 > > 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 >
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 > > > 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) >