Обсуждение: Performance
Looking for a little reasoning behind our performance difference on 2 different platforms. We have been running postgres on our sparcs, and have come to rely on the dB quite heavily. We have dedicated a box to doing nothing but our postgres work. Here is what we have: Dual Sparc 167 512 MB RAM Solaris 2.5.1 Performance seemed reasonable to us, until we ran the same database and queries on the following machine: Intel Celeron 333 128 MB RAM Red Hat Linux 5.2 We have a passwd style database with 65,000 rows. We updated 20,000 of them with a SQL update command, setting a single integer field to a value. Both boxes where indexed the same, and had identical data. The Sparc took near 10 minutes to complete, while the Intel took ~30 seconds. This is just one case, but many very similar tests had the same results. Now I love Linux, and the price compared to a Sparc makes it much simpler to get one on line. However, I can't understand why the Sparc would lag so far behind. We are starting Postgres the same on both machines: su - postgres -c "/usr/local/pgsql/bin/postmaster -B 256 -o -F -i -S" We are looking at getting a dual 400 Intel Pentium II box with Red Hat to migrate all of the Postgres work to. But in the meantime, is there a way to optimize the performance on the Sparc? Thanks in advance. -Jason Neumeier.
Starting several months back, at work, I've been pushing our Unix department away from Sparcs and onto Intel servers (IBM Netfinity)...the main reason being cost/performance just isn't there for the Sparcs. never was, but the Intel servers, until recently, haven't been the most stable to run off of. Using the rc5 client as a 'benchmark' (what else has programmers working hard to optimize their code to get the best numbers on it?), we found that when comparing a Dual-PII 450 against an Sparc E450/400Mhz, the E450 came in at ~30% less powerful then the Dual-PII ... If you take a look at http://infopad.EECS.Berkeley.EDU/CIC/summary/local, it shows comparisons of the various CPUs out there, up until Nov/98 ... the Intel CPUs blow away the Sparc chip's in integer arithmetic, while the Sparc excels in floating point. Your operating system, and the database, tends to do most stuff in integer, so you get performance boons that way... The other thing to consider is that you are comparing two differences, not just one. Different CPUs and different operating systems. Solaris isn't nicknamed 'slowaris' for nothing :) Its a bloated OS, albeit stable... On Tue, 30 Mar 1999, Jason wrote: > Looking for a little reasoning behind our performance difference on 2 > different platforms. We have been running postgres on our sparcs, and > have come to rely on the dB quite heavily. We have dedicated a box to > doing nothing but our postgres work. Here is what we have: > > Dual Sparc 167 > 512 MB RAM > Solaris 2.5.1 > > Performance seemed reasonable to us, until we ran the same database and > queries on the following machine: > > Intel Celeron 333 > 128 MB RAM > Red Hat Linux 5.2 > > We have a passwd style database with 65,000 rows. We updated 20,000 of > them with a SQL update command, setting a single integer field to a > value. Both boxes where indexed the same, and had identical data. The > Sparc took near 10 minutes to complete, while the Intel took ~30 > seconds. This is just one case, but many very similar tests had the > same results. > > Now I love Linux, and the price compared to a Sparc makes it much > simpler to get one on line. However, I can't understand why the Sparc > would lag so far behind. We are starting Postgres the same on both > machines: > > su - postgres -c "/usr/local/pgsql/bin/postmaster -B 256 -o -F -i -S" > > We are looking at getting a dual 400 Intel Pentium II box with Red Hat > to migrate all of the Postgres work to. But in the meantime, is there a > way to optimize the performance on the Sparc? Thanks in advance. > > -Jason Neumeier. > > > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Tue, 30 Mar 1999, The Hermit Hacker wrote: [snip] > Using the rc5 client as a 'benchmark' (what else has programmers working > hard to optimize their code to get the best numbers on it?), we found that > when comparing a Dual-PII 450 against an Sparc E450/400Mhz, the E450 came > in at ~30% less powerful then the Dual-PII ... > > If you take a look at http://infopad.EECS.Berkeley.EDU/CIC/summary/local, > it shows comparisons of the various CPUs out there, up until Nov/98 ... > the Intel CPUs blow away the Sparc chip's in integer arithmetic, while the > Sparc excels in floating point. Your operating system, and the database, > tends to do most stuff in integer, so you get performance boons that > way... > > The other thing to consider is that you are comparing two differences, not > just one. Different CPUs and different operating systems. Solaris isn't > nicknamed 'slowaris' for nothing :) Its a bloated OS, albeit stable... > The original poster noted using Solaris 2.5.1 -- been there, done that, it certainly can be slow. A long time ago, I contacted Sun about this. They acknowledged a problem with the dynamic library loading routines. I have a Dual Sparc 125/512 running Solaris 2.6 and a dual pentium-100 running 2.5.1. I'll test some to see if this might be 2.5 v. 2.6 OS differences, although there is stil the underlying hardware issue. The second point however, is clock speeds. Two 167 CPUs <> One 333 CPU. The third is the SPARC chip's cache versus the Intel chip's cache. I know SUN and Ross were making chips with as little as 128 cache, and the SPEC marks for the 128 v. 256 v 512 v 1024 cache are phenomenal. So just out of curiousity, what's the cache size on the SPARC and Intel chips respectively? > On Tue, 30 Mar 1999, Jason wrote: > > > Looking for a little reasoning behind our performance difference on 2 > > different platforms. We have been running postgres on our sparcs, and > > have come to rely on the dB quite heavily. We have dedicated a box to > > doing nothing but our postgres work. Here is what we have: > > > > Dual Sparc 167 > > 512 MB RAM > > Solaris 2.5.1 > > > > Performance seemed reasonable to us, until we ran the same database and > > queries on the following machine: > > > > Intel Celeron 333 > > 128 MB RAM > > Red Hat Linux 5.2 > > > > We have a passwd style database with 65,000 rows. We updated 20,000 of > > them with a SQL update command, setting a single integer field to a > > value. Both boxes where indexed the same, and had identical data. The > > Sparc took near 10 minutes to complete, while the Intel took ~30 > > seconds. This is just one case, but many very similar tests had the > > same results. > > > > Now I love Linux, and the price compared to a Sparc makes it much > > simpler to get one on line. However, I can't understand why the Sparc > > would lag so far behind. We are starting Postgres the same on both > > machines: > > > > su - postgres -c "/usr/local/pgsql/bin/postmaster -B 256 -o -F -i -S" > > > > We are looking at getting a dual 400 Intel Pentium II box with Red Hat > > to migrate all of the Postgres work to. But in the meantime, is there a > > way to optimize the performance on the Sparc? Thanks in advance. > > > > -Jason Neumeier. > > > > > > > > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy > Systems Administrator @ hub.org > primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org > > >
On Tue, 30 Mar 1999, The Hermit Hacker wrote:
# Using the rc5 client as a 'benchmark' (what else has programmers working
# hard to optimize their code to get the best numbers on it?), we found
# that when comparing a Dual-PII 450 against an Sparc E450/400Mhz, the
# E450 came in at ~30% less powerful then the Dual-PII ...
That's a *horrible* benchmark. How often do your servers sit
around doing math inside of cache? This isn't raytracing.
# If you take a look at
# http://infopad.EECS.Berkeley.EDU/CIC/summary/local, it shows comparisons
# of the various CPUs out there, up until Nov/98 ... the Intel CPUs blow
# away the Sparc chip's in integer arithmetic, while the Sparc excels in
# floating point. Your operating system, and the database, tends to do
# most stuff in integer, so you get performance boons that way...
This is absolutely incorrect. My database tends to do most stuff
in I/O. In the real world, I've not seen sign of a machine that could
keep up with my SPARCs 24/7.
# The other thing to consider is that you are comparing two differences,
# not just one. Different CPUs and different operating systems. Solaris
# isn't nicknamed 'slowaris' for nothing :) Its a bloated OS, albeit
# stable...
It's nicknamed ``Slowaris'' for the same reason FreeBSD is
nicknamed, ``FleaBeastie'' and Linux is nicknamed ``Linsux'' and HP-UX is
nicknamed ``HP-SUX'' etc...
# On Tue, 30 Mar 1999, Jason wrote:
#
# > Looking for a little reasoning behind our performance difference on 2
# > different platforms. We have been running postgres on our sparcs, and
# > have come to rely on the dB quite heavily. We have dedicated a box to
# > doing nothing but our postgres work. Here is what we have:
# >
# > Dual Sparc 167
# > 512 MB RAM
# > Solaris 2.5.1
# >
# > Performance seemed reasonable to us, until we ran the same database and
# > queries on the following machine:
# >
# > Intel Celeron 333
# > 128 MB RAM
# > Red Hat Linux 5.2
# >
# > We have a passwd style database with 65,000 rows. We updated 20,000 of
# > them with a SQL update command, setting a single integer field to a
# > value. Both boxes where indexed the same, and had identical data. The
# > Sparc took near 10 minutes to complete, while the Intel took ~30
# > seconds. This is just one case, but many very similar tests had the
# > same results.
# >
# > Now I love Linux, and the price compared to a Sparc makes it much
# > simpler to get one on line. However, I can't understand why the Sparc
# > would lag so far behind. We are starting Postgres the same on both
# > machines:
# >
# > su - postgres -c "/usr/local/pgsql/bin/postmaster -B 256 -o -F -i -S"
# >
# > We are looking at getting a dual 400 Intel Pentium II box with Red Hat
# > to migrate all of the Postgres work to. But in the meantime, is there a
# > way to optimize the performance on the Sparc? Thanks in advance.
# >
# > -Jason Neumeier.
# >
# >
# >
#
# Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
# Systems Administrator @ hub.org
# primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
#
#
#
--
SA, beyond.com My girlfriend asked me which one I like better.
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________
On Tue, 30 Mar 1999, Dustin Sallings wrote:
> On Tue, 30 Mar 1999, The Hermit Hacker wrote:
>
> # Using the rc5 client as a 'benchmark' (what else has programmers working
> # hard to optimize their code to get the best numbers on it?), we found
> # that when comparing a Dual-PII 450 against an Sparc E450/400Mhz, the
> # E450 came in at ~30% less powerful then the Dual-PII ...
>
> That's a *horrible* benchmark. How often do your servers sit
> around doing math inside of cache? This isn't raytracing.
My servers do more math inside of cache then they do raytracing...
:)
Anyway, regardless...for the price of that one Sparc E450 we
picked up, I could pick up *easily* a dozen Dual-PII 450 servers, and run
something like Beowulf on it to do the raytracing...
Wait, isn't that what IBM just did? Built a Beowulf cluster of
Netfnity servers for ~$150k, that outperformed a $5.5Million Cray? And, I
*thought* they did something like raytracing with it...I can't remmeber
the full article, but it was ... enlightening. If you want me to dig
aruond and find the URL to it, please ask...
> It's nicknamed ``Slowaris'' for the same reason FreeBSD is
> nicknamed, ``FleaBeastie'' and Linux is nicknamed ``Linsux'' and HP-UX is
> nicknamed ``HP-SUX'' etc...
>
Welp, I've been educated today then...I didn't know FreeBSD or
Linux had nicknames :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Tue, 30 Mar 1999, The Hermit Hacker wrote:
# Anyway, regardless...for the price of that one Sparc E450 we
# picked up, I could pick up *easily* a dozen Dual-PII 450 servers, and
# run something like Beowulf on it to do the raytracing...
#
# Wait, isn't that what IBM just did? Built a Beowulf cluster of
# Netfnity servers for ~$150k, that outperformed a $5.5Million Cray? And,
# I *thought* they did something like raytracing with it...I can't
# remmeber the full article, but it was ... enlightening. If you want me
# to dig aruond and find the URL to it, please ask...
As soon as postgres becomes a distributed database, the above will
become relevant. For now, you need to build it all into a single box with
a lot of I/O and a decent amount of CPU and RAM. Each of my 336Mhz
Ultra-SPARC processors has 4MB of CPU cache and 1GB of RAM. I currently
only have four processors in each box, but they'll hold 14. We didn't buy
them for this, though, we bought them for I/O.
--
SA, beyond.com My girlfriend asked me which one I like better.
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________
[snip]
>
> The third is the SPARC chip's cache versus the Intel chip's cache. I know
> SUN and Ross were making chips with as little as 128 cache, and the SPEC
> marks for the 128 v. 256 v 512 v 1024 cache are phenomenal. So just out
> of curiousity, what's the cache size on the SPARC and Intel chips
> respectively?
1) All Celerons ship with a 128K on chip cache. Which means the cache runs
at the same clock rate as the chip.
2) The PIIs ship with 512K cache, however it's level 2 so it only runs at bus
speed.
3) The Xeon has different sizes of on chip cache that runs at the clock speed.
The Xeon is _the_ processor to be used in a highly loaded server based on the
Intel architecture.
>
> > On Tue, 30 Mar 1999, Jason wrote:
> >
> > > Looking for a little reasoning behind our performance difference on 2
> > > different platforms. We have been running postgres on our sparcs, and
> > > have come to rely on the dB quite heavily. We have dedicated a box to
> > > doing nothing but our postgres work. Here is what we have:
> > >
> > > Dual Sparc 167
> > > 512 MB RAM
> > > Solaris 2.5.1
> > >
> > > Performance seemed reasonable to us, until we ran the same database
> > > and queries on the following machine:
> > >
> > > Intel Celeron 333
> > > 128 MB RAM
> > > Red Hat Linux 5.2
> > >
> > > We have a passwd style database with 65,000 rows. We updated 20,000
> > > of them with a SQL update command, setting a single integer field to a
> > > value. Both boxes where indexed the same, and had identical data.
> > > The Sparc took near 10 minutes to complete, while the Intel took ~30
> > > seconds. This is just one case, but many very similar tests had the
> > > same results.
> > >
> > > Now I love Linux, and the price compared to a Sparc makes it much
> > > simpler to get one on line. However, I can't understand why the Sparc
> > > would lag so far behind. We are starting Postgres the same on both
> > > machines:
> > >
> > > su - postgres -c "/usr/local/pgsql/bin/postmaster -B 256 -o -F -i -S"
> > >
> > > We are looking at getting a dual 400 Intel Pentium II box with Red Hat
> > > to migrate all of the Postgres work to. But in the meantime, is there
> > > a way to optimize the performance on the Sparc? Thanks in advance.
> > >
> > > -Jason Neumeier.
> > >
> > >
> > >
> >
> > Marc G. Fournier ICQ#7615664 IRC Nick:
> > Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org
> > secondary: scrappy@{freebsd|postgresql}.org
> >
> >
> >
>
>
>
> 1) All Celerons ship with a 128K on chip cache. Which means the cache runs > at the same clock rate as the chip. > 2) The PIIs ship with 512K cache, however it's level 2 so it only runs at bus > speed. No, it runs at half the core speed. Maarten ps. do you also find it annoying when ppl quote whole messages when they have only a one-line answer? Please trim down your posts..... -- Maarten Boekhold, boekhold@tibco.com TIBCO Finance Technology Inc. The Atrium Strawinskylaan 3051 1077 ZX Amsterdam, The Netherlands tel: +31 20 3012158, fax: +31 20 3012358 http://www.tibco.com
> > 1) All Celerons ship with a 128K on chip cache. Which means the cache > > runs at the same clock rate as the chip. 2) The PIIs ship with 512K > > cache, however it's level 2 so it only runs at bus speed. > > No, it runs at half the core speed. Oh shoot. You are absolutely right. I'm terribly sorry. > > Maarten > > ps. do you also find it annoying when ppl quote whole messages when they > have only a one-line answer? Please trim down your posts..... :-) That's funny. Although I think ppl do this for the archives. That way when someone is searching for an answer and reads an email they don't need to go scouring for the entire thread and can get all the info in that one email. Just a thought. Anyway thanks for your correction. > > -- > > Maarten Boekhold, boekhold@tibco.com > TIBCO Finance Technology Inc. > The Atrium > Strawinskylaan 3051 > 1077 ZX Amsterdam, The Netherlands > tel: +31 20 3012158, fax: +31 20 3012358 > http://www.tibco.com >
On Wed, 31 Mar 1999, Rudy Gireyev wrote:
> :-) That's funny. Although I think ppl do this for the archives. That way when
> someone is searching for an answer and reads an email they don't need to go
> scouring for the entire thread and can get all the info in that one email. Just a
> thought. Anyway thanks for your correction.
That is why there is a 'thread' button on the archives :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org