I continue my benchmarks of Intel SSD 910, previous time I compared it with Fusion-io ioDrive http://www.mysqlperformanceblog.com/2012/09/07/intel-ssd-910-in-tpcc-mysql-benchmark/. Now I want to test this card against RAID over spinning disks.
- Server: Dell PowerEdge R710
- CPU: 2x Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz
- Memory: 192GB
- Storage: Hardware RAID10 over 8 disks, card: Perc H710, disks: Seagate ST9750420AS 750GB, 2.5″, 7200RPM, 16MB, SATA. Intel SSD 910 (software RAID over 2x200GB devices)
- Filesystem: ext4
- OS: Ubuntu 12.04.1
- MySQL Version: Percona Server 5.5.27-28.1
- Benchmark name: tpcc-mysql
- Scale factor: 2500W (~250GB of data)
- Benchmark length: 2h for SSD, 4h for HDD RAID, but the result is taken only for last 1h to remove warm-up phase
Results
There is a jitter graph of Throughput taken every 10 sec:
I put number of median throughput, so we can estimate a performance gain.
Or in text form:
| BP size | HDD RAID | Intel SSD 910 | Ratio (i910/raid) |
| 25 GB | 228 | 1620 | 7.1 |
| 50 GB | 552 | 3182 | 5.76 |
| 75 GB | 1094 | 5729 | 5.24 |
So gain is in 5-7x range, which is quite decent.
One thing to pay attention is a density of results. In case with RAID it is much more dense.
So I build a graph where throughput is shown every second:
The variation of throughput with Intel SSD 910 is much bigger, though I am not totally sure what is the main contributor into that: the card of itself
or MySQL internals + flushing logic.
Now, all these results are received with innodb_flush_log_at_trx_commit=2, which in comments to previous post was called cheating.
So I ran another round with innodb_flush_log_at_trx_commit=1 to see what kind of penalty to expect.
There is some penalty of using innodb_flush_log_at_trx_commit=1, but it is not significant.
Conclusion
In conclusion I see that for its price (around $2000 on date of publishing) Intel SSD 910 handles MySQL workload quite well, I did not face any problem working with this card. I think Intel SSD 910 is suitable to use with MySQL / Percona Server, especially if you are looking for quick performance boost in IO heavy workload.
i would like to see some mysql benchmark and comparison on this ssd:
http://eshop.macsales.com/item/OWC/SSDMEP6G400/
You wrote that changing innodb_flush_log_at_trx_commit from 2 to 1 didn’t make much difference in the performance of the SSD drive, which is interesting.
Did it make a difference with the HDD RAID10?
With spinning RAID-1 media, we notice a huge difference between those two settings (a factor of 10). I’d be interested to know if you see the same results on your spinning media. If you do, that suggests that using SSDs solves the same performance problems that “innodb_flush_log_at_trx_commit=2″ solves, without the drawback of lowering ACID guarantee levels.
if you use innodb_flush_log_at_trx_commit=1 with HDD RAID you need to have a writeback cache mode, otherwise you will see the performance hit as you described.
Agreed — I just found it interesting that (if I understood correctly) your testing suggests that a writeback cache is not needed for “innodb_flush_log_at_trx_commit=1″ performance when using SSDs, which is great. Moving to more standard, off-the-shelf commodity hardware (SATA SSDs) is much better than having to buy expensive proprietary battery-backed RAID cards.