The Intel SSD DC S3700 (200GB) Review

Enterprise Storage Bench - Oracle Swingbench

We begin with a popular benchmark from our server reviews: the Oracle Swingbench. This is a pretty typical OLTP workload that focuses on servers with a light to medium workload of 100 - 150 concurrent users. The database size is fairly small at 10GB, however the workload is absolutely brutal.

Swingbench consists of over 1.28 million read IOs and 3.55 million writes. The read/write GB ratio is nearly 1:1 (bigger reads than writes). Parallelism in this workload comes through aggregating IOs as 88% of the operations in this benchmark are 8KB or smaller. This test is actually something we use in our CPU reviews so its queue depth averages only 1.33.

The S3700's only performance blemish is here in our Swingbench test. Like many other new drives we've looked at (e.g. Intel's SSD 910, Micron's P320h), the S3700's performance here is a regression compared to previous drives. I asked Intel about this and it appears that largely unaligned smaller-than-4KB accesses are slower on the new controller compared to the outgoing 710. My guess is that given how common 4KB accesses are, most controller vendors picked it as the optimization point for their next-gen drives. I'm not entirely sure how many enterprise applications exist that fall into this behavior pattern but it's worth pointing out in case you have a unique workload that features a lot of < 4KB unaligned accesses.

Update: I have some more clarification as to what's going on here. There are two components to the Swingbench test we're running here: the database itself, and the redo log. The redo log stores all changes that are made to the database, which allows the database to be reconstructed in the event of a failure. In good DB design, these two would exist on separate storage systems, but in order to increase IO we combined them both for this test. Accesses to the DB end up being 8KB and random in nature, a definite strong suit of the S3700 as we've already shown. The redo log however consists of a bunch of 1KB - 1.5KB, QD1, sequential accesses. The S3700, like many of the newer controllers we've tested, isn't optimized for low queue depth, sub-4KB, sequential workloads like this. 

Remember that with 25nm NAND, the page size grew to 8KB. Having tons of small IOs like this creates extra tracking overhead, which can require additional DRAM to maintain full performance. Intel views this type of a scenario as unlikely (apparently the latest versions of Oracle allow you to force the redo log to use 4KB sectors instead of 512B sectors, which would make these transfers 8KB - 12KB in size), and thus simply didn't optimize for it with the S3700's firmware. Intel did confirm that should customer feedback indicate this is a fairly likely scenario that it would be willing to consider some alternate solutions to improving performance here, but at this point it seems like it doesn't matter for the vast majority of use cases.