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

From: William Yu <wyu(at)talisys(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Opteron vs Xeon (Was: What to do with 6 disks?)
Date: 2005-04-20 15:09:37
Message-ID: d45rbn$pbq$1@news.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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
>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Richard van den Berg 2005-04-20 15:15:37 Re: When are index scans used over seq scans?
Previous Message Tom Lane 2005-04-20 14:39:21 Re: When are index scans used over seq scans?