Thread: intel vs amd benchmark for pg server part 2

intel vs amd benchmark for pg server part 2

From
postgres@vrane.com
Date:
Because of a lot of unwarranted
criticizms of my previous rigorous and outstanding :)
benchmark and because I am lucky to come
across a bargain maxtor drive I have done the test
again.

It put the same hard drive in both amd 1.33GHz
and celeron 566MHz machine with exactly
the same controller that comes with the drive.
It's promise PDC20269 chipset and
I have to run 2.4.19-pre7-ac2 to detect this
controller and linux detects it as udma_133 drive.
I point PGDATA to the directory on this hard drive on both machines.

On amd

# hdparm  -tT /dev/hde

/dev/hde:
 Timing buffer-cache reads:   128 MB in  0.78 seconds =164.10 MB/sec
 Timing buffered disk reads:  64 MB in  1.59 seconds = 40.25 MB/sec

On celeron the first number is around 100 MB/sec and
the second number is about the same.  The drive is not in that
system anymore and I didn't write the numbers down.

The minimun time to vacuum on celeron I got was 61 seconds
and whereas on amd it is 59 seconds.  So it looks like vacuuming
scales very linearly with hdparm results.

And yes, with on board ide controller, AMD/sis box hdparm bottleneck is around
24MB/sec whereas corresponding number for intel box is 30MB/sec.

The moral I get from this benchmark is that AMD is certainly
not much better preformance/price wise at least not for
a database server

In fact for various reasons I am going to go with an intel
box.

Another gripe I have is that vacuum process does not eat up 100%
of cpu.  In the beginning it peaks around 80% and at the end
it is stuck around 20%.

Whenever I have a long running process and
it is not eating up 100% of cpu I feel I am not getting my money's
worth for the cpu.  I wonder why vacuum process is not more parallelized
if at all.  I can imagine manually vacuuming many tables in parallel
and it might eat up all cpu and I wonder whether it might finish quicker.




Re: intel vs amd benchmark for pg server part 2

From
Jeffrey Baker
Date:
On Fri, Apr 26, 2002 at 10:52:35PM -0400, postgres@vrane.com wrote:
> Another gripe I have is that vacuum process does not eat up 100%
> of cpu.  In the beginning it peaks around 80% and at the end
> it is stuck around 20%.
>
> Whenever I have a long running process and
> it is not eating up 100% of cpu I feel I am not getting my money's
> worth for the cpu.  I wonder why vacuum process is not more parallelized
> if at all.  I can imagine manually vacuuming many tables in parallel
> and it might eat up all cpu and I wonder whether it might finish quicker.

I think you must not have very much experience with databases.  They
are totally limited by the disk (storage) subsystem.  You know, the
part of your machine that has to wait 10 or more milliseconds for a
little metal arm to swing into position.  Very retro!

I'd be pissed off if vacuum was taking that much of my CPU time.
Usually it wails away on the disks (8 15000RPM monsters) and the
CPUs twiddle their thumbs.

As for IDE controllers: they are all fifth-rate crap.  Get a SCSI
controller.

-jwb


Re: intel vs amd benchmark for pg server part 2

From
Lincoln Yeoh
Date:
Erm. I think you've missed the point slightly.

All that CPU power is so that you can watch movies and play MP3s whilst
waiting for VACUUM to finish[1]. Be sure to have your movie files on
another disk and I/O channel, so that frames don't get lost - but of course ;).

Note: if you really don't need the CPU power, what you could do is
underclock your CPU, that way you can run cooler and more reliably (maybe
even go fanless) or you can get someone else to do it for you and buy a
Celeron.

Hope that helps,
Link.

[1] When you are vacuuming really large databases you might even want to
crack crypto whilst you're at it :). Or do some ray tracing, or
machinima/animated films. Of course with the advances of Postgresql 7.2
these times of repose and reflection will become briefer, rarer and more
precious. How we will miss glimpses of The Boss yelling and hammering on
the locked server room door whilst the vacuum is going on. But take heart,
for the Benevolent Developers in their great wisdom and grace hath provided
VACUUM FULL, and our disk buffers overfloweth with joy.

At 10:52 PM 4/26/02 -0400, postgres@vrane.com wrote:

>The moral I get from this benchmark is that AMD is certainly
>not much better preformance/price wise at least not for
>a database server
>
>In fact for various reasons I am going to go with an intel
>box.
>
>Another gripe I have is that vacuum process does not eat up 100%
>of cpu.  In the beginning it peaks around 80% and at the end
>it is stuck around 20%.
>
>Whenever I have a long running process and
>it is not eating up 100% of cpu I feel I am not getting my money's
>worth for the cpu.  I wonder why vacuum process is not more parallelized
>if at all.  I can imagine manually vacuuming many tables in parallel
>and it might eat up all cpu and I wonder whether it might finish quicker.



Re: intel vs amd benchmark for pg server part 2

From
Curt Sampson
Date:
On Fri, 26 Apr 2002 postgres@vrane.com wrote:

> Another gripe I have is that vacuum process does not eat up 100%
> of cpu.  In the beginning it peaks around 80% and at the end
> it is stuck around 20%.

That's because your disk subsystem is too slow for the machine.
Put in a disk subsystem that doesn't slow down the machine, and
you'll use all your CPU.

Then you can complain about not using all your disk I/O capacity.

Performance bottlenecks never go away. You can only move them around.

cjs
--
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC


Re: intel vs amd benchmark for pg server part 2

From
Michael Loftis
Date:

Curt Sampson wrote:

>On Fri, 26 Apr 2002 postgres@vrane.com wrote:
>
>>Another gripe I have is that vacuum process does not eat up 100%
>>of cpu.  In the beginning it peaks around 80% and at the end
>>it is stuck around 20%.
>>
>
>That's because your disk subsystem is too slow for the machine.
>Put in a disk subsystem that doesn't slow down the machine, and
>you'll use all your CPU.
>
>Then you can complain about not using all your disk I/O capacity.
>
>Performance bottlenecks never go away. You can only move them around.
>
Thats why we all call it "chasing the brass ring" :)

>
>cjs
>



Re: intel vs amd benchmark for pg server part 2

From
pgsql-gen Newsgroup (@Basebeans.com)
Date:
Subject: Re: [GENERAL] intel vs amd benchmark for pg server part 2
From: Vic Cekvenich <vic@basebeans.com>
 ===

Or a disk caching controler (like Mylex or Penging Computing)
Any DB is IO bound.

Michael Loftis wrote:
>
>
> Curt Sampson wrote:
>
>> On Fri, 26 Apr 2002 postgres@vrane.com wrote:
>>
>>> Another gripe I have is that vacuum process does not eat up 100%
>>> of cpu.  In the beginning it peaks around 80% and at the end
>>> it is stuck around 20%.
>>>
>>
>> That's because your disk subsystem is too slow for the machine.
>> Put in a disk subsystem that doesn't slow down the machine, and
>> you'll use all your CPU.
>>
>> Then you can complain about not using all your disk I/O capacity.
>>
>> Performance bottlenecks never go away. You can only move them around.
>>
> Thats why we all call it "chasing the brass ring" :)
>
>>
>> cjs
>>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>    (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)