This post is a response to this month’s T-SQL Tuesday #119 prompt by Alex Yates. T-SQL Tuesday is a way for the SQL Server Community to share ideas about different database and professional topics every month. This month’s topic asks us to write about something in your IT career that you have changed your mind about. What was your original opinion? Why did you believe that? What do you believe now? Why did you change your mind?.
I’ve been writing and presenting about SQL Server hardware for many years now. I actually wrote a book called SQL Server Hardware back in 2011, which is probably the only book about server hardware from a SQL Server perspective. During most of my coverage of SQL Server hardware related topics, I have been a big proponent of using Intel processors for SQL Server workloads. I even used to make joking comments during some of my presentations about how AMD probably had a contract out on me, because I gave such negative opinions about their processors for SQL Server usage. There were valid reasons why I had a negative opinion of AMD processors though.
Why I Used to Only Recommend Intel Processors
After the introduction of the 45nm Intel Nehalem microarchitecture in 2008, Intel was completely dominant compared to AMD when it came to single-threaded CPU performance for server processors. Intel was also successfully executing their Tick-Tock release cadence, where they released a new CPU microarchitecture roughly every two years (a Tock) and then introduced a manufacturing process shrink on the same basic microarchitecture (with minor improvements) the following year (a Tick).
This Tick-Tock release cycle made it easier to plan when to push for a hardware upgrade or a complete data platform refresh. Figure 1 shows the Intel Server Processor Family Tree from 2008 to the present. The Tick-Tock model was in place from 2007 until early 2016. During this period, Intel captured over 99% of the overall x86 server CPU market, with many server vendors discontinuing their AMD-based server models. The situation was so bad that Microsoft offered a 25% license cost discount if you used qualifying AMD processors with Biztalk Server and SQL Server 2012 or 2014 in a document called the Core Factor Table.
Figure 1: Intel Server Processor Family Tree
When SQL Server 2012 was released on April 1, 2012, it brought with it a move to core-based licensing for SQL Server, which replaced the old processor-based licensing that was used in previous versions of SQL Server. This licensing change made it very important to do some careful analysis before selecting the exact processor(s) for a database server or virtualization host that was going to be running SQL Server VMs.
This licensing change by Microsoft happened shortly after the introduction of the ill-fated 32nm AMD Bulldozer microarchitecture, which featured up to 16 physical cores in the Opteron 6200 series. Unfortunately, these AMD processors had very poor single-threaded performance and high power usage to go with their high SQL Server licensing costs. This was not a good combination, hence the Microsoft Core Factor Table.
For licensing purposes, Microsoft didn’t care whether you had a fast processor core or a slow processor core, the license price per core was exactly the same. Knowing this, a smart database professional could purposely select the fastest processor SKU at a given core count, and also try to select a lower core count (but faster) processor SKU in order to get the most performance per core and in order to minimize their SQL Server core license costs.
If you did this properly, it was pretty easy to save many tens of thousands of dollars on SQL Server core license costs on a two-socket server, which would more than offset the hardware cost of of a typical two-socket database server. Using a frequency-optimized processor SKU would also deliver better single-threaded CPU performance and more memory bandwidth than an entry level processor SKU at the same core count.
Why I Now Recommend You Seriously Consider AMD Processors
For Opteron server processors, AMD was stuck with the Bulldozer microarchitecture (and minor improvements with the newer Piledriver and Excavator microarchitectures) until the release of the completely new Zen architecture in 2017. During this period, Intel continued to completely dominate the server CPU market, with no meaningful competition from AMD, except on the low-end. As often happens with a lack of competition, the market leader became complacent over time, to the point where AMD was able to catch up and actually surpass Intel in many areas. As a result, AMD is starting to regain some market share in the server CPU market.
Intel has badly stumbled over the past 4-5 years as they have tried to move from a 14nm manufacturing process to a 10nm manufacturing process. This has forced them to abandon the old Tick-Tock release cycle, and it has also lead to a longer product cycle overall.
This has been accompanied by a very noticeable reduction in generational performance increases since Broadwell-EP, as shown in Figure 2. These numbers are estimated TPC-E scores for a two-socket server with two, eight-core processors, using the fastest eight-core processor from each generation. Based on this, we have seen an extremely small increase in performance over the last four years.
Figure 2: Generational Intel Xeon Processor Performance Increases
Intel Security Vulnerabilities
Intel has also had to deal with multiple processor security vulnerabilities. These include Spectre, Meltdown, Foreshadow and their variants, along with newer exploits such as Zombieload. The latest CPU security vulnerability I have heard of is NetCAT, which only affects Intel processors.
Generally speaking, modern Intel processors are more vulnerable to these types of attacks than modern AMD processors are. The required fixes for these vulnerabilities also have a more negative effect on performance for Intel processors than on AMD processors, especially since AMD processors are not affected by many of these exploits. Microsoft’s current SQL Server specific guidance about this subject is here.
On August 7, 2019, AMD finally unveiled their new 7nm EPYC 7002 Series of server processors, formerly code-named “Rome” at the AMD EPYC Horizon Event in San Francisco. This is the second generation EPYC server processor that uses the same Zen 2 architecture as the AMD Ryzen 3000 Series desktop processors. These new processors are socket compatible with the previous generation 14nm AMD EPYC 7001 Series processors, so they will work in existing model servers (with a BIOS update). Despite that, you will need a new model server to be able to use PCIe 4.0 support from the newer processors. The major server vendors like Dell/EMC and HPE have already released new server models that let you fully leverage the new AMD EPYC 7002 series processors.
AMD is not slowing the pace of innovation, since they are on track to release the Zen 3 based “Milan” server processors in Q3/Q4 of 2020. These will have IPC improvements, better L3 cache performance, and probably increased clock speeds.
Figure 3: AMD EPYC 7000 Series Roadmap
I have previously written about why the AMD EPYC 7002 Series processors are going to be significant for SQL Server. The 7nm EPYC 7002 series has higher memory density and capacity, higher memory speed and bandwidth, more PCIe bandwidth, PCIe 4.0 support, and much lower pricing than 14nm Intel Cascade Lake-SP processors.
A one-socket AMD server will be a superior replacement for many legacy two-socket Intel servers, while a two-socket AMD server will also be a superior replacement for many legacy four-socket Intel servers. I think we will see AMD’s server CPU market share go up to 10-15% over the next 12-18 months. We may also see more aggressive pricing from Intel as a result (which has already happened with the new Intel Cascade Lake-X HEDT and Xeon W workstation processors).
I think an AMD platform is a viable choice for many SQL Server workloads, so I have changed my mind compared to what I thought in the past.
2 Responses to T-SQL Tuesday #119 Changing Your Mind
I really enjoy your hardware posts on SQL Server, Glenn.
Thanks for sharing and keeping us updated.
Thanks for the kind words! I appreciate the feedback.