Обсуждение:

Поиск
Список
Период
Сортировка

От
"Steve Wolfe"
Дата:
   Last week I did the benchmarking on a dual Athlon vs. a quad Xeon, and
thought I'd report.

  The benchmark was a simple Perl script which would read in a file of SQL
statements, fork off an arbitrary number of processes, and go through the
entire list of queries in every child process, recording the overall time
to completion.

  That methodology does have it's drawbacks, but for my purposes, it will
give me a fair representation of what kind of capacity I can expect from a
server.  The query list was obtained by logging actual queries sent to our
production server, and thus it may or may not reflect performance in YOUR
situation.  It also means that these numbers DO NOT correlate to ANY OTHER
benchmark in any manner.  The list consisted of 1,000 queries.

  The first machine is a SuperMicro 8050 with 4 700 MHz Xeons, 1 MB of
level 2 cache, 1.5 gigs of RAM.  The second system is a dual Athlon MP
1800+ with 1 gig of RAM.  Both used the following command to start the
postmaster for this test:

su postgres -c '/usr/local/pgsql/bin/postmaster -i -S -B 32768 -N 96 -d
3 -D/usr/local/pgsql/data -o "-F -S 98304"'

  Because fsync was turned off and the entire database kept in disk cache,
the disk I/O should (theoretically) NOT have had an impact on this test.
If it were, it would favor the Xeon machine, having a SCSI RAID array vs.
a single IDE drive in the Athlon.

   After running the test for various numbers of simultaneous clients
(1..10,16,24,32,48,64), I computed the "qpm", or "queries per minute".
The quad Xeon handled 1,000 QPM for one connection, and peaked at 1759 QPM
at 9 connections.  At 16 queries, it was at 1720 QPM, and at 64
connetions, had dropped off to 1148.

   The Athlon system handled 2727 QPM with a single connection, and peaked
at 4091 QPM with 6 connections.  With 16, it was still handling 3855 QPM,
and had dwindled to 3257 with 64 connections.

   My conclusions?  Dual Athlons are FAST.   Interestingly enough, they
also seemed to scale better than the quad Xeon, keeping 79% of their peak
performance with 64 simultaneous connections, as opposed to 65% with the
Xeon-based system.  Compiling PostgreSQL, OpenSSL, OpenSSH, and the Linux
kernel was ridiculously fast.

   As an interesting side note, after the tests, I used the parts for
their intended purpose - to upgrade one of our web servers.  Afterward, I
compared it to the performance of a couple of dual P3/866 web servers.  In
this setting, the dual Athlons did not fare as well as I thought they
would.  They handled about 35% more traffic than the P3's, but I had
expected much more.  I think it's interesting how the system shined so
well in one setting, but not nearly as well in another.

steve



Re:

От
Tom Lane
Дата:
"Steve Wolfe" <steve@iboats.com> writes:
>    Last week I did the benchmarking on a dual Athlon vs. a quad Xeon, and
> thought I'd report.

Which PG version was this?

            regards, tom lane

Re:

От
David Griffiths
Дата:
Couple of questions about your last comment:

- the benchmark against the dual-P3's was as a web server?
- what was the config of the dual P3 machine?
- could the slow-down be attributed to something other than CPU performance?
IE lots of disk reads, with the P3 system having a better disk-system? Or
perhaps they have equivilent hard-drive configurations, but they are
disk-bound and thus the Athalon doesn't get to shine? Perhaps the Athalon
system is not fully maxed?

I've heard that there is a kernal bug with the Athalon (Microsoft has a
registry patch for it). Maybe only with nVidia graphics cards? Couldn't find
a reference.

LinuxHardware.org did a nice review of a Dual Athalon +1800 (compared to
various systems). Shows that (surprise surprise) dual processors are only
useful if you have software that can take advantage of multiple processors.
The url:
http://www.linuxhardware.org/article.pl?sid=01/10/15/1443234&mode=thread

David

>    As an interesting side note, after the tests, I used the parts for
> their intended purpose - to upgrade one of our web servers.  Afterward, I
> compared it to the performance of a couple of dual P3/866 web servers.  In
> this setting, the dual Athlons did not fare as well as I thought they
> would.  They handled about 35% more traffic than the P3's, but I had
> expected much more.  I think it's interesting how the system shined so
> well in one setting, but not nearly as well in another.


Re:

От
Bruno Wolff III
Дата:
On Tue, Feb 19, 2002 at 03:22:09PM -0800,
  David Griffiths <dgriffiths@boats.com> wrote:
>
> I've heard that there is a kernal bug with the Athalon (Microsoft has a
> registry patch for it). Maybe only with nVidia graphics cards? Couldn't find
> a reference.

This got press on /. and other places. Some memory addresses used by AGP
cards is marked as cacheable when large (1MB?) segments are used to map
some of the kernel address space. This is incorrect.
When data in that area of memory is read with some Athlon processors
the cached data is written back to memory even though the data wasn't
changed. However, by that time the data may have already been changed
by the AGP card, which is a problem.