On January 9, Intel launched the 22nm Intel Xeon E5-2400 v2 Product Family (Ivy Bridge-EN) of processors for two-socket servers. For SQL Server usage, this is not a good processor family to choose for a new server.
While these processors are a nice improvement over the older 32nm Intel Xeon E5-2400 Product Family (Sandy Bridge-EN) of processors, they are still a particularly poor choice for SQL Server 2012 and SQL Server 2014, when compared to a 22nm Intel Xeon E5-2600 v2 Product Family (Ivy Bridge-EP) processor with the same physical core count.
The reason for this is that Microsoft simply charges for physical core licenses with SQL Server 2012 and SQL Server 2014 (in non-virtualized servers). The performance characteristics of the processor do not matter at all to Microsoft (for licensing purposes). Given this fact, it does not make any sense to pick a lower performance processor with the same number of physical cores, at least from a performance or scalability perspective. From a strict economic perspective, a lower performance processor (with the same core count) will cost a little bit less money, and it is likely to use less electrical power and require less heat dissipation in your data center. These cost savings are pretty small compared to the cost of SQL Server core licenses, and you are giving up a lot of performance to save a relatively small amount of money.
If you compare the best models from the the entry-level E5-2400 v2 line to the best models from the E5-2600 v2 line, you will notice significantly higher base and turbo clock speeds, along with larger L3 cache sizes from the higher-end E5-2600 v2 line. You will also see higher QPI bandwidth, higher memory speed support and twice the memory capacity with the E5-2600 v2 line. The E5-2407 v2 processor does not have Turbo Boost or Hyper-Threading, which helps explain its very low price for a server-level processor.
Processor | Cores | Base Speed | Turbo Speed | L3 Cache | QPI | Price |
E5-2407 v2 | 4 | 2.4GHz | 2.4GHz | 10MB | 6.4GT/s | $250.00 |
E5-2430 v2 | 6 | 2.5Ghz | 3.0GHz | 15MB | 7.2GT/s | $551.00 |
E5-2450 v2 | 8 | 2.5GHz | 3.3GHz | 20MB | 8.0GT/s | $1,107.00 |
E5-2470 v2 | 10 | 2.4GHz | 3.2GHz | 25MB | 8.0GT/s | $1,440.00 |
Table 1: Intel Xeon E5-2400 v2 Product Family Specifications
Processor | Cores | Base Speed | Turbo Speed | L3 Cache | QPI | Price |
E5-2637 v2 | 4 | 3.5GHz | 3.8GHz | 15MB | 8.0GT/s | $996.00 |
E5-2643 v2 | 6 | 3.5GHz | 3.8GHz | 25MB | 8.0GT/s | $1,552.00 |
E5-2667 v2 | 8 | 3.3GHz | 4.0GHz | 25MB | 8.0GT/s | $2,057.00 |
E5-2690 v2 | 10 | 3.0GHz | 3.6GHz | 25MB | 8.0GT/s | $2,057.00 |
E5-2697 v2 | 12 | 2.7GHz | 3.5GHz | 30MB | 8.0GT/s | $2,618.00 |
Table 2: Intel Xeon E5-2600 v2 Product Family Specifications
Just to be clear, you won’t see these processors being offered in the same model servers. For example, the Dell PowerEdge R320, R420, and R520 servers will have the Xeon E5-2400 (Sandy Bridge-EN) or Xeon E5-2400 v2 (Ivy Bridge-EN) processors (which you don’t want for SQL Server usage). The Dell PowerEdge R620, R720 and R720xd servers will have the Xeon E5-2600 (Sandy Bridge-EP) or Xeon E5-2600 v2 (Ivy Bridge-EP) processors (which you do want for SQL Server usage).
As a final observation, the major server vendors are still offering the older 32nm Sandy Bridge along with the newer 22nm Ivy Bridge processors in most of their servers. In the cases I have seen, there is no discount for the older, slower, more power hungry Sandy Bridge processors, so there is really no good reason to choose one of the older Sandy Bridge processors.
6 thoughts on “One Intel Processor Family to Avoid For SQL Server 2012/2014”
Playing devils advocate here; do you think that Microsoft would benefit charging on a CPU performance basis? Or is that potentially the thin end of the wedge? (I don’t actually believe they should just would like to hear your thoughts on it (apologies if this was posted twice!)
Hi Richard,
I don’t want to see Microsoft go down that road. It would make licensing much more complicated, and probably would not yield that much revenue. It would also encourage more people to want to buy lower-performance processors.
Another question is how Microsoft would measure CPU performance. Something simplistic, like base clock speed can be quite misleading if you are comparing across different processor families.
Reading your comments and looking at the chart and i have to say Intel was right to offer slightly slower servers at a slightly reduced cost. For Bank of America where money is not a concern and they need to process a billion transactions per second with distributed queries then every instruction cycle counts. For a small business owner where my longest query is an automated report generated daily that takes only 10 seconds, swapping processors to reduce my QTI performance only by 20% is a no-brainier. As you rightfully pointed out $746 per server is not a big savings but it is a weeks salary for an employee. In today’s economy these are the differences between operating a company and a operating a company efficiently.
Leon
Leon,
Well, it really depends on what your database server is being used for and how many people are relying on it to do their jobs on a daily basis. Saving a few seconds (or minutes) each time a query or report runs could pretty quickly pay for the pretty small incremental cost of a fast processor, especially when multiple employees are affected. The database server is likely to be in service for at least 3-5 years, so spending a few hundred dollars more for that server is going to be pretty insignificant to most companies. If things are really so tight that a few hundred dollars is really an issue, there are probably much more serious issues going on with the business.
My main point was/is that incremental processor costs pale when compared to SQL Server license costs. By choosing the right processor, you can quite often run a given workload on a smaller number of processor cores and save a huge amount of money on the overall cost of the server.
Hi Glenn,
How much do you think that the leaning towards dense low power CPUs for virtualisation hosts is adding to stories of poor user experience post virtualisation.
Best Regards,
Bob
I am sure that trend contributes to stories of poor performance and poor user experience. Running virtualized SQL Server workloads on hosts that have low performance processors is not going to benefit performance…
I would also guess that more performance problems are caused by oversubscription and lack of host resources (CPU, memory, and I/O) to properly support the total workload.