SQL101: AMD EYPC 7000 Series Processors

As Kimberly blogged about earlier this year, SQLskills has an ongoing initiative to blog about basic topics, which we’re calling SQL101. We’re all blogging about things that we often see done incorrectly, technologies used the wrong way, or where there are many misunderstandings that lead to serious problems. If you want to find all of our SQLskills SQL101 blog posts, check out SQLskills.com/help/SQL101.

On June 20, 2017, AMD officially unveiled its new EPYC 7000 Series processor line for one and two-socket servers. These 14nm processors are based on the same Zen architecture as the recent AMD Ryzen desktop processors, with competitive single-threaded performance, along with very high core counts, memory density, and PCIe 3.0 lane counts.

These processors are a system on a chip (SoC) that includes CPU, memory controller, I/O controller and Server Controller Hub, so that no separate chipset is required. They have up to 32 physical cores per SoC, along with Simultaneous Multithreading (SMT), so you get 64 logical cores per SoC. You also get eight memory channels per socket, which means 16 DDR4 DIMMs per socket. This lets you have up to 2TB of RAM in a one-socket server, and 4TB of RAM in a two-socket server (with 128GB DIMMs). More realistically, you can easily and affordably have 512GB of RAM in a single-socket server with 32GB DIMMs.

You also get 128 PCIe 3.0 lanes per socket, which gives you a lot of total I/O capability. One very nice feature of these processors is that AMD does not cripple the lower-end SKUs when it comes to SMT, memory channels or PCIe 3.0 lanes, which is a big, welcome difference from how Intel does things with their product differentiation.

Another difference from Intel (which I actually don’t like) is that AMD does not have higher base clock speeds in their lower core count SKUs, so the existing strategy to reduce your SQL Server core license costs and also get better single-threaded performance by picking “frequency-optimized” low core count (LCC) processors, such as the Intel Xeon E5-2667 v4 is not going to work the same way.

What you can and should do, is to pick the fastest AMD EPYC SKU available at a given physical core count. For example, there are three EPYC 7000 SKUs that have 32 physical cores, the EPYC 7501, the EPYC 7551, and the EPYC 7601. Since the SQL Server core license cost will be the same, you should pick the EPYC 7601, to get the most performance possible for your license dollars.

Another important caveat is for SQL Server Standard Edition users. SQL Server 2016 Standard Edition has a license limit of four sockets or 24 physical cores, whichever is lower. This means that you need to be very careful what processor you choose for SQL Server 2016 Standard Edition. You basically have five choices to avoid exceeding these license limits.

You can get a 24-core EPYC 7401P, or a 16-core EPYC 7351P for a single-socket server. The 32-core EPYC 7551P would exceed your Standard Edition license limit. In a two-socket server, you can choose an eight-core EPYC 7251, and populate either one or two sockets. You can also choose a 16-core EPYC 7351 or a 24-core EPYC 7451 and just populate one socket of a two-socket server.

If you buy a new database server that has more than 24 physical cores, SQL Server 2016 Standard Edition will only use 24 physical cores per instance, but Microsoft will still expect you to pay for a core license for every physical core present in the machine. This could be a very expensive mistake. In a worst case scenario, you buy a two-socket server with two of the 32-core EPYC 7601 processor, and end up having to pay about $72K in extra license costs for cores that you are not allowed to use in a single instance.

Microsoft has not formally announced any change in these license limits for SQL Server 2017 Standard Edition, but hopefully they will raise these license limits to a more realistic value for modern processors from AMD (and for the upcoming Intel Skylake-SP processors).

SQL Server Diagnostic Information Queries for June 2017

This month, there are some minor updates to the all of the versions of the queries. I usually make additional minor updates to the queries during the month, so if you are in doubt, downloading the latest version is always a good idea.

Rather than having a separate blog post for each version, I have just put the links for all seven major versions in this single post. There are two separate links for each version. The first one on the top left is the actual diagnostic query script, and the one below on the right is the matching blank results spreadsheet, with labeled tabs that correspond to each query in the set.

Here are links to the latest versions of these queries for SQL Server 2017, 2016, 2014 and 2012:

SQL Server 2017 Diagnostic Information Queries

SQL Server 2017 Blank Results Spreadsheet

SQL Server 2016 Diagnostic Information Queries

SQL Server 2016 Blank Results Spreadsheet

SQL Server 2014 Diagnostic Information Queries

SQL Server 2014 Blank Results Spreadsheet

SQL Server 2012 Diagnostic Information Queries

SQL Server 2012 Blank Results Spreadsheet

Here are links to the most recent versions of these scripts for SQL Server 2008 R2 and older:

Since SQL Server 2008 R2 and older are out of Mainstream support from Microsoft (and because fewer of my customers are using these old versions of SQL Server), I am not going to be updating the scripts for these older versions of SQL Server every single month going forward.  I started this policy a while ago, and so far, I have not heard any complaints. I did update these queries slightly in January 2017 though.

SQL Server 2008 R2 Diagnostic Information Queries (CY 2017)

SQL Server 2008 R2 Blank Results Spreadsheet

SQL Server 2008 Diagnostic Information Queries (CY 2017)

SQL Server 2008 Blank Results Spreadsheet

SQL Server 2005 Diagnostic Information Queries (CY 2017)

SQL Server 2005 Blank Results Spreadsheet

The basic instructions for using these queries is that you should run each query in the set, one at a time (after reading the directions for that query). It is not really a good idea to simply run the entire batch in one shot, especially the first time you run these queries on a particular server, since some of these queries can take some time to run, depending on your workload and hardware. I also think it is very helpful to run each query, look at the results (and my comments on how to interpret the results) and think about the emerging picture of what is happening on your server as you go through the complete set. I have quite a few comments and links in the script on how to interpret the results after each query.

After running each query, you need to click on the top left square of the results grid in SQL Server Management Studio (SSMS) to select all of the results, and then right-click and select “Copy with Headers” to copy all of the results, including the column headers to the Windows clipboard. Then you paste the results into the matching tab in the blank results spreadsheet.

About half of the queries are instance specific and about half are database specific, so you will want to make sure you are connected to a database that you are concerned about instead of the master system database. Running the database-specific queries while being connected to the master database is a very common mistake that I see people making when they run these queries.

Note: These queries are stored on Dropbox. I occasionally get reports that the links to the queries and blank results spreadsheets do not work, which is most likely because Dropbox is blocked wherever people are trying to connect. I am not planning on moving these to Github any time soon.

I also occasionally get reports that some of the queries simply don’t work. This usually turns out to be an issue where people have some of their user databases in 80 compatibility mode, which breaks many DMV queries, or that someone is running an incorrect version of the script for their version of SQL Server.

It is very important that you are running the correct version of the script that matches the major version of SQL Server that you are running. There is an initial query in each script that tries to confirm that you are using the correct version of the script for your version of SQL Server. If you are not using the correct version of these queries for your version of SQL Server, some of the queries are not going to work correctly.

If you want to understand how to better run and interpret these queries, you should consider listening to my three related Pluralsight courses, which are SQL Server 2014 DMV Diagnostic Queries – Part 1SQL Server 2014 DMV Diagnostic Queries – Part 2 and SQL Server 2014 DMV Diagnostic Queries – Part 3. All three of these courses are pretty short and to the point, at 67, 77, and 68 minutes respectively. Listening to these three courses is really the best way to thank me for maintaining and improving these scripts…

Please let me know what you think of these queries, and whether you have any suggestions for improvements. Thanks!