THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Linchi Shea

Checking out SQL Server via empirical data points

Hexa-core and query parallelism

I was struck by two things yesterday. One was that internet—the blogsphere in particular—was abuzz over the leaked information on Intel Dunnington chip, which is a six-core processor that is socket-compatible with Intel Tigerton (i.e. Xeon 7300). Do a Google search on the keywords: Intel Dunnington, and you’ll find plenty of information.

 

The other thing was that I got involved with a client in yet another round of discussions concerning query parallelism, which was prompted by a Microsoft support’s recommendation to turn off query parallelism for some batch processing because of certain problems with parallelism.

 

Intel as well as AMD is clearly on the march along their roadmap towards multi-core and many-core chips. And that is putting a lot of pressure on the software development community to ensure that their software can take full advantage of this rapid increase in computing power. The pace of hardware progress is outstripping that of software development. Among all the software applications, DBMS including SQL Server are relatively better positioned to keep pace with this multi-core/many-core march because they are inherently multi-threaded (or multi-tasked).

 

That said, programming parallelism is not trivial, and programming scalable parallelism is hard. If you have worked with SQL Server query parallelism in its current state, you know it doesn’t always do exactly what you want. With multi cores/many cores becoming a norm, you won’t afford to just turn it off when there is a problem here or there, as it is currently a ‘generally accepted’ practice. Query parallelism needs to become a lot more robust. And since it’s just not realistic to be completely problem free, query parallelism also needs to become a lot more granular so that the problem can be localized and if it comes to it, query parallelism can be turned on or off in isolated area.

 

The six-core Dunnington processor will be released second half of this year. That corresponds more or less with the release of SQL Server 2008. Note that four-socket servers are common. With Dunnington, that gives us 24 cores on a commodity server. And there are also some eight-socket x64 servers, though less common. And that would give us 48 cores on a commodity server. It’ll be interesting to see how SQL Server 2008 scales on these 24-core or 48-core x64 commodity servers.

Published Thursday, February 28, 2008 1:03 PM by Linchi Shea

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Glenn Berry said:

I agree that more work needs to be done to make parallel programming and parallel query execution more robust and better performing. At the same time, having 24 cores in a commodity level server is a good thing for scalability, even for OLTP workloads, where MAXDOP = 1.

Not to mention that Dunnington is based on the Penryn architectecture, with the addition of a huge L3 cache. Based on my experience at NewsGator (where we saw huge gains going from Paxville to Tulsa) because of the big L3 cache, I am still excited about Dunnington.

February 28, 2008 1:35 PM
 

Denis Gobo said:

>>And that is putting a lot of pressure on the software development community to ensure that their software can take full advantage of this rapid increase in computing power

A good start is here:

http://msdn2.microsoft.com/en-us/concurrency/default.aspx

February 28, 2008 4:29 PM

Leave a Comment

(required) 
(required) 
Submit

About Linchi Shea

Checking out SQL Server via empirical data points

This Blog

Syndication

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement