Thread: Performance

Performance

From
Jason
Date:
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.



Re: [GENERAL] Performance

From
The Hermit Hacker
Date:
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


Re: [GENERAL] Performance

From
Statistical Solutions
Date:

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


Re: [GENERAL] Performance

From
Dustin Sallings
Date:
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. ____________


Re: [GENERAL] Performance

From
The Hermit Hacker
Date:
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


Re: [GENERAL] Performance

From
Dustin Sallings
Date:
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. ____________


Re: [GENERAL] Performance

From
"Rudy Gireyev"
Date:
[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
> >
> >
> >
>
>
>



Re: [GENERAL] Performance

From
Maarten Boekhold
Date:
> 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

Re: [GENERAL] Performance

From
"Rudy Gireyev"
Date:
> > 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
>



Re: [GENERAL] Performance

From
The Hermit Hacker
Date:
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