Comments for SSD Performance Blog

Comment on Testing the Micron P320h by George Payton

George Payton — Tue, 07 May 2013 17:19:25 +0000

Can you show how this Micron card tests vs the FlashMax II?

Comment on Virident vCache vs. FlashCache: Part 1 by Ernie Souhrada

Ernie Souhrada — Fri, 03 May 2013 05:16:43 +0000

@Michael–

I can’t speak for Virident’s official policy since I don’t work for them, but if I had to guess I would say that the probability isn’t that high. vCache is a part of the Virident device driver package, and as far as I know, it only works with Virident cards, so if you were to buy a Virident card you’d get vCache automatically (once it goes GA). If you don’t have a Virident card, having access to the vCache module via kernel upstream isn’t likely to be of much benefit.

Comment on Virident vCache vs. FlashCache: Part 1 by Michael Gebetsroither

Michael Gebetsroither — Thu, 02 May 2013 08:44:36 +0000

So flashcache and vCache are both good, but dm-cache and bcache are merged upstream.

What are the goals at getting vCache merged upstream? (i really like to see vCache being merged!)

Comment on On SSDs – Lifespans, Health Measurement and RAID by Ovais Tariq

Ovais Tariq — Tue, 12 Feb 2013 09:20:42 +0000

Hi Sean,

Hot spare would only be used when one of the drives in the RAID 1 array fails. In which case you would already have the full life of the SSD available, so rotating hot spares over a couple of months, in my opinion, is not going to give any additional benefit. The lifespan of the SSDs is governed by how many writes it has received and not strictly by its age.

Comment on On SSDs – Lifespans, Health Measurement and RAID by Sean

Sean — Sun, 10 Feb 2013 15:51:56 +0000

Ovais, this is one of the clearest posts I’ve seen about SSD and their lifespans. Thank you. I wasn’t aware that there is a good chance of both drives failing around the same time.

I’m building a new server for a start-up client and going with RAID-1 SSD for the DB and OS. Wouldn’t a simple solution be to rotate your hot spare a couple months in? This seems a logical step to increase data safety given that one SSD’s end of life is couple months ahead of the other.

Comment on On SSDs – Lifespans, Health Measurement and RAID by Ovais Tariq

Ovais Tariq — Sat, 24 Nov 2012 11:55:55 +0000

Carl,

I assume that you are suggesting that the company you work for, manufacture SSDs that meet the specifications you mentioned. If such is true, it would be good to lay a hand on it and test drive

Comment on Testing Fusion-io ioDrive2 Duo by Stanley

Stanley — Mon, 05 Nov 2012 07:14:46 +0000

why don’t you test the performance of random write in sync mode with sysbench fileio ?

Comment on Intel SSD 910 vs HDD RAID in tpcc-mysql benchmark by Robert Mathews

Robert Mathews — Mon, 29 Oct 2012 18:42:16 +0000

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.

Comment on Intel SSD 910 vs HDD RAID in tpcc-mysql benchmark by Vadim Tkachenko

Vadim Tkachenko — Sun, 28 Oct 2012 23:54:28 +0000

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.

Comment on Intel SSD 910 vs HDD RAID in tpcc-mysql benchmark by Robert Mathews

Robert Mathews — Sun, 28 Oct 2012 23:33:14 +0000

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.