Hewlett Packard Enterprise Persistent Memory

Hewlett Packard Enterprise (HPE) has announced a new product that uses non-volatile DIMMs (NVDIMMs), which they are calling Persistent Memory. This short video gives a high level view of how it works, via a whiteboard time lapse. The initial product is an 8GB module which has 8GB of DRAM backed by 8GB of flash for $899.00, which is pretty pricey!

 

Figure 1: HPE 8GB NVDIMM

HPE has a blog post with some more details about their SQL Server testing using NVDIMMs.

They compared the OLTP database performance of a SQL Server database running on an HP DL360 Gen9 server in two scenarios. The details they provide are frustratingly incomplete. They don’t specify what version of SQL Server, what operating system, what type of SSDs, etc.

First Scenario:

  • Data file(s) on six 400GB SSDs
  • Log file on two mirrored SSDs (so two SSDs in RAID 1)
  • 970K transactions/minute
  • 373 µs log write latency

Second Scenario:

  • Data file(s) on six 400GB SSDs
  • Log file on two mirrored SSDs, with two mirrored NVDIMMs as a write-back cache in front of the SSDs
  • 1.08M transactions/minute
  • 181 µs log write latency

 

DB OLTP.jpg

Figure 2: HPE SQL Server Testing with NVDIMMs

 

These results are actually not as impressive as I would expect on the surface, so I would be very curious to more details behind their testing. For example, was their workload previously limited by how fast it could write to the transaction log? After they started using NVDIMMs, did they run into a different bottleneck, such as CPU utilization?

I also want to know more details how this is implemented, with existing server models and existing operating systems. It looks like there is a driver that excludes the DIMM slots that are being used by NVDIMMs from being visible to the operating system as conventional memory, and instead makes them available as a write-back cache layer for an existing storage device. It looks like you can combine multiple NVDIMMs into a single, mirrored cache layer in front of a single storage device. This seems pretty similar in concept to the hardware memory cache in a RAID controller.

This might be pretty useful if you have a workload that is actually seeing bottlenecks writing to a transaction log (or perhaps you have multiple databases with log files on the same logical drive), and you don’t want to use the Delayed Durability feature in SQL Server 2014 and newer or the In-memory OLTP features in SQL Server 2014 Enterprise Edition and newer.

Eight Different Ways to Clear the SQL Server Plan Cache

Nearly anytime you see the command DBCC FREEPROCCACHE mentioned in a blog post, magazine article or book, you usually get some sort of a scary warning about how you should not use it on a production system, or else life as we know it will end. For example, Books Online says this:

Use DBCC FREEPROCCACHE to clear the plan cache carefully. Freeing the plan cache causes, for example, a stored procedure to be recompiled instead of reused from the cache. This can cause a sudden, temporary decrease in query performance. For each cleared cachestore in the plan cache, the SQL Server error log will contain the following informational message: “SQL Server has encountered %d occurrence(s) of cachestore flush for the ‘%s’ cachestore (part of plan cache) due to ‘DBCC FREEPROCCACHE’ or ‘DBCC FREESYSTEMCACHE’ operations.” This message is logged every five minutes as long as the cache is flushed within that time interval.

I would argue that running DBCC FREEPROCCACHE does not cause that much distress with a modern processor, even on a very busy OLTP system. It will cause a pretty minor CPU spike for a few seconds on most systems as the query plans get recompiled as they are executed. It can actually be pretty useful for resetting the cached_time time for sys.dm_exec_procedure_stats so that it is the same for most of the stored procedures in your normal workload. That makes it easier to pick out your most expensive queries or stored procedures on a cumulative basis when you are looking at things like total worker time or total logical reads.

Having said all that, I want to show a few methods for clearing all or part of the plan cache that are somewhat less impactful on the system. Running DBCC FREEPROCCACHE is kind of a brute force approach, so if you are concerned about that, you can run one of the variations shown below:

-- Eight different ways to clear the plan cache
-- Glenn Berry
-- SQLskills.com
    


-- Example 1 ***********************
-- Remove all elements from the plan cache for the entire instance 
DBCC FREEPROCCACHE;


-- Example 2 ***********************
-- Flush the plan cache for the entire instance and suppress the regular completion message
-- "DBCC execution completed. If DBCC printed error messages, contact your system administrator." 
DBCC FREEPROCCACHE WITH NO_INFOMSGS;


-- Example 3 ***********************
-- Flush the ad hoc and prepared plan cache for the entire instance
DBCC FREESYSTEMCACHE ('SQL Plans');


-- Example 4 ***********************
-- Flush the ad hoc and prepared plan cache for one resource pool

-- Get Resource Pool information
SELECT name AS [Resource Pool Name], cache_memory_kb/1024.0 AS [cache_memory (MB)], 
        used_memory_kb/1024.0 AS [used_memory (MB)]
FROM sys.dm_resource_governor_resource_pools;

-- Flush the ad hoc and prepared plan cache for one resource pool
DBCC FREESYSTEMCACHE ('SQL Plans', 'LimitedIOPool');


-- Example 5 **********************
-- Flush the entire plan cache for one resource pool

-- Get Resource Pool information
SELECT name AS [Resource Pool Name], cache_memory_kb/1024.0 AS [cache_memory (MB)], 
        used_memory_kb/1024.0 AS [used_memory (MB)]
FROM sys.dm_resource_governor_resource_pools;


-- Flush the plan cache for one resource pool
DBCC FREEPROCCACHE ('LimitedIOPool');
GO


-- Example 6 **********************
-- Remove all elements from the plan cache for one database (does not work in SQL Azure) 

-- Get DBID from one database name first
DECLARE @intDBID INT;
SET @intDBID = (SELECT [dbid] 
                FROM master.dbo.sysdatabases 
                WHERE name = N'AdventureWorks2014');

-- Flush the plan cache for one database only
DBCC FLUSHPROCINDB (@intDBID);



-- Example 7 **********************
-- Clear plan cache for the current database

USE AdventureWorks2014;
GO
-- Clear plan cache for the current database
-- New in SQL Server 2016 and SQL Azure
ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE;



-- Example 8 **********************
-- Remove one query plan from the cache

USE AdventureWorks2014;
GO

-- Run a stored procedure or query
EXEC dbo.uspGetEmployeeManagers 9;

-- Find the plan handle for that query 
-- OPTION (RECOMPILE) keeps this query from going into the plan cache
SELECT cp.plan_handle, cp.objtype, cp.usecounts, 
DB_NAME(st.dbid) AS [DatabaseName]

[text][/text]

FROM sys.dm_exec_cached_plans AS cp CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS st 
WHERE OBJECT_NAME (st.objectid)

[text][/text]

LIKE N'%uspGetEmployeeManagers%' OPTION (RECOMPILE); 

-- Remove the specific query plan from the cache using the plan handle from the above query 
DBCC FREEPROCCACHE (0x050011007A2CC30E204991F30200000001000000000000000000000000000000000000000000000000000000);

 

SQL Server 2012 Service Pack 3 CU2 Available

On March 21, 2016, Microsoft released SQL Server 2012 Service Pack 3 CU2, which is Build 11.0.6523.0. This Cumulative Update has 20 hotfixes in the Public fix list, which is a relatively low number for a SQL Server 2012 Cumulative Update.

If you are running SQL Server 2012, I think you should be moving to the SP3 branch pretty soon, if you have not done so already. The SP2 branch is still supported until November 2016, but the RTM and SP1 branches are no longer supported.

Here are links to the Microsoft CU lists for both current Service Packs.

SQL Server 2012 SP2 build versions

SQL Server 2012 SP3 build versions