Re: Opteron vs Xeon (Was: What to do with 6 disks?)

In terms of vendor specific models -

Does anyone have any good/bad experiences/recommendations for a 4-way
Opteron from Sun (v40z, 6 internal drives) or HP (DL585 5 internal
drives) models?

This is in comparison with the new Dell 6850 (it has PCIexpress, faster
FSB 667MHz, which doesn't match up with AMD's total IO bandwidth, but
much better than previous 6650s).

Thanks,
Anjan


-----Original Message-----
From: William Yu [mailto:wyu@talisys.com]
Sent: Wednesday, April 20, 2005 11:10 AM
To: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Opteron vs Xeon (Was: What to do with 6 disks?)

I posted this link a few months ago and there was some surprise over the

difference in postgresql compared to other DBs. (Not much surprise in
Opteron stomping on Xeon in pgsql as most people here have had that
experience -- the surprise was in how much smaller the difference was in

other DBs.) If it was across the board +100% in MS-SQL, MySQL, etc --
you can chalk in up to overall better CPU architecture. Most of the time

though, the numbers I've seen show +0-30% for [insert DB here] and a
huge whopping +++++ for pgsql. Why the pronounced preference for
postgresql, I'm not sure if it was explained fully.

BTW, the Anandtech test compares single CPU systems w/ 1GB of RAM. Go to

dual/quad and SMP Xeon will suffer even more since it has to share a
fixed amount of FSB/memory bandwidth amongst all CPUs. Xeons also seem
to suffer more from context-switch storms. Go > 4GB of RAM and the Xeon
suffers another hit due to the lack of a 64-bit IOMMU. Devices cannot
map to addresses > 4GB which means the OS has to do extra work in
copying data from/to > 4GB anytime you have IO. (Although this penalty
might exist all the time in 64-bit mode for Xeon if Linux/Windows took
the expedient and less-buggy route of using a single method versus
checking whether target addresses are > or < 4GB.)



Jeff Frost wrote:
> On Tue, 19 Apr 2005, J. Andrew Rogers wrote:
>
>> I don't know about 2.5x faster (perhaps on specific types of loads),
>> but the reason Opterons rock for database applications is their
>> insanely good memory bandwidth and latency that scales much better
>> than the Xeon.  Opterons also have a ccNUMA-esque I/O fabric and two
>> dedicated on-die memory channels *per processor* -- no shared bus
>> there, closer to real UNIX server iron than a glorified PC.
>
>
> Thanks J!  That's exactly what I was suspecting it might be.
Actually,
> I found an anandtech benchmark that shows the Opteron coming in at
close
> to 2.0x performance:
>
> http://www.anandtech.com/linux/showdoc.aspx?i=2163&p=2
>
> It's an Opteron 150 (2.4ghz) vs. Xeon 3.6ghz from August.  I wonder if

> the differences are more pronounced with the newer Opterons.
>
> -Jeff
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if
your
>      joining column's datatypes do not match
>

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org