Re: Opteron vs Xeon (Was: What to do with 6 disks?) - Mailing list pgsql-performance
From | Anjan Dave |
---|---|
Subject | Re: Opteron vs Xeon (Was: What to do with 6 disks?) |
Date | |
Msg-id | 4BAFBB6B9CC46F41B2AD7D9F4BBAF785098970@vt-pe2550-001.vantage.vantage.com Whole thread Raw |
Responses |
Re: Opteron vs Xeon (Was: What to do with 6 disks?)
Re: Opteron vs Xeon (Was: What to do with 6 disks?) Re: Opteron vs Xeon (Was: What to do with 6 disks?) |
List | pgsql-performance |
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
pgsql-performance by date: