March 5, 2008 at 12:18 am
Comments posted to this topic are about the item Terry-bites
March 5, 2008 at 6:52 am
We have moved many of our databases from 32bit 2000 servers to 64bit 2005 servers. Hardware is similar between 32bit and 64bit with the exception of 16gigs of ram on 32bit and 64gigs of ram on 64bit. Servers are typically hp580 g4's (dual core) or g5's (quad core) with fully loaded cpu sockets and multiple p800 controllers with multiple msa70's fully loaded. Some databases are decision support and some are oltp.
The biggest benefit of the extra memory on 64bit systems that we have seen has been shifting the bottleneck away from the disk systems. Disk systems are now almost idle in some systems where they use to be our biggest bottleneck.
We have also noticed significant performance increases with the hp580 g5's, which have the new quad core processors and also more pci-x 8 slots for our disk controllers. (Prior models primarily used pci-x 4 slots unless you purchased raiser adapters to convert two pci-x 4 slots to a single pci-x 8 slot)
Our comparisons are not true apples to apples since our 32bit systems are sql 2000 and the 64bit systems are sql 2005.
March 5, 2008 at 7:07 am
Interesting to hear. Do you have some comparisons of loads between the systems? Interested in writing up something on your experiences moving to 64-bit?
March 5, 2008 at 8:19 am
Assuming Windows 7 or whatever's next can make use of it.
Windows Vista 64-bit can use 128gb of memory for Ultimate, Business, and Enterprise editions (16gb/8gb for Home Premium/Basic). I would think it is reasonable to assume that any subsequent version of Windows would not be able to handle less.
Mark
March 5, 2008 at 1:10 pm
Steve, what type of load information are you looking for?
I can summarize some of our findings of moving to sql server 2005 64bit.
From a warehousing perspective we have seen huge gains in performance. I attribute a lot of this due to extra memory available to for data cache, which can be verified by running “dbcc dropcleanbuffers” and watching performance drop until the cache is refreshed. The memory cache in 32bit was too small for our large tables to remain in data cache, which stressed our disk systems. I also attribute the performance increase to the faster optimization in sql 2005. We utilize a star schema and have some large views based on 50+ tables and 300+ columns that are used for ad-hoc queries. In sql server 2000 the optimization times hovered around 120 seconds versus 15 seconds for sql server 2005. It’s possible these fast times would also be seen in sql server 2005 32bit, but we don’t have any sql server 2005 32bit systems to compare against.
From an oltp perspective, I can’t really say we have seen huge performance gains. There have been some, but there have also been instances that we have seen small queries that normally run in 1 second on sql server 2000 32 bit run in 1-2 seconds in sql server 2005. Even Microsoft acknowledges that there is a little extra overhead in sql server 2005 to keep track of all the new statistics that are now tracked and can be view in the dm views. We have seen much lower hardware utilization through perfmon, but I am sure some of this is due to newer hardware.
We did convert a third party portfolio management/account system from Sybase 64bit to sql server 2005 64bit. Below are some of the specifications and findings.
Old system: Sybase ase 12.5 64bit, Sun Fire 2900 with 16 cores, 32 gigs of ram, two storedge 6120 cabinets each with a dedicated controller with 1gig of cache and 14 drives raid 10 (one for data and the other for logs and tempdb).
New system: Sql Server 2005 64bit, Hp580 g5 with 16 cores, 64 gigs of ram, two p800 controllers with 512 cache and each with an msa70 with 24 drives raid 10 (one for data and the other for logs), one p400 controller with 512 cache and 8 internal drives raid 10 (used for tempdb)
Moving to sql 2005 and new hardware, we are seeing sustained data transfer rates of 600-700 megs (1 gig peaks) vs less than 200 megs on the sun direct attached storage. Database reindexing takes one forth the time. The processor utilization during our intensive pricing process hovers between 10%-15% vs 60%-70% on the sun equipment. Our application is a very thick client, so we did not see as drastic of a drop in the application, but did see most processes running in half the time. We are not really comparing apples to apples since the sun equipment is several years old. The application vendor has confirmed that sql server needs about half the number of intel processors vs Sybase on unix.
Based on my experiences so far, I can honestly say that I have no desire to go back to 32bit sql server and deal with trying to manage usage of the 3gigs of natively addressable memory available. In 64bit, I can run sql sever, analysis services, reporting services, etc. all on the same server with acceptable performance.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply