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
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.