MySQL with SSD drives - Part Two
I have been pointed to a RAM-disk based device called the HyperDrive4 by a recent comment of a reader of the previous post on SSD drives. It is a “relatively” cheap device that looks to be solidly build- battery backup (with optional automatic hard drive copy in case of power failure). I did say relatively cheap. I think the basic 32GB unit runs about $3,500 (plus RAM). It seems to currently top out at 32GB.
Even so, it is would incredible to have one of these in your server to run the most used indexing files and tables. I know 32 gigs isn’t that much these days but if necessary you can RAID these things to build larger disks. The throughput and access times on these is just incredible. Take a look here:
http://www.hyperossystems.co.uk/
Click on the “more information” button underneath the hyperdrive4 unit to see the product line.
So do I get to test one now?
8 Comments so far
Leave a reply
It all sounds good but I still would like the prives for this stuff to get far beloe prices for RAM.
For 10K$ you can get box with 32G of RAM now and if your database fits in ram you’re typically fine anyway.
There are little issues like Warmup. Data reads should happen from the buffer pool (considering you use Innodb) and data writes happen in background anyway and should be fine unless you have extreme number of random writes. Log writes go to BBU and so fast.
There are possible issues with Innodb writes on some workloads though.
Thanks for the feedback Peter. That is why I put posts like this up
For the price of the RAM drive..you are right. Generally it would make more sense to just stuff in more RAM to the server.
That seems to be the general way we are going here..expanding RAM to put more on a server. I guess I just like expensive toys so this hyperdrive unit caught my eye.
However, I think many people have db’s that wouldn’t fit in 32G..or even 64G of RAM (which from what I understand is all that MySQL will handle gracefully). For those cases, and if ultra-high performance was needed, it would be nice to tack the RAM-drive unit on to help out with i/o throughput.
The comment about BBU triggered a thought. I searched through your blog and came across this:
this is from June the 6th.
Can you explain what write-back and write-through are? Why does write-back help performance? Basically if you could elaborate on that in relation to your BBU it would be very helpful.
thanks,
Keith
How does this compare to the RAMSAN: http://www.superssd.com/products/tera-ramsan/ ?
Hi Keith,
There are two modes of operation for the write cache in a RAID controller:
* Write-through — In this mode, a write is not acknowledged until it has been written to the actual disk. This mode is safe without a battery backup unit.
* Write-back — This mode holds your pending write in the RAM of the RAID controller and immediately acknowledges the write. The data is later flushed to the actual disk in bulk. This mode is not safe unless you have a functional battery backup unit.
The biggest gain you will ever see because of a RAID with BBU is on sequential committed writes, such as transaction log files (InnoDB logs and binary logs). Typically you think of “sequential write” being the optimal case for writes, but with transaction logs, each small chunk is individually committed, so you lose all of the benefits of them being sequential normally. If you have a RAID with BBU set to write-back, you can get most of that benefit back by allowing the RAID controller to group a bunch of small writes together (in the RAID controller RAM) into a larger write.
What kind of a difference does it make? Huge. On purely sequential committed writes in write-through mode, you will see about the disk’s theoretical limit in writes, that is for e.g. 6×15k disks in a RAID 10, you will see 3×15k worth of writes before the system is maxed out, which is ~750 writes per second. Using write-back mode, you would see many thousands of writes per second (easily 2-3k, often much higher, depending on the size of the writes).
Why do you need the BBU? When operating in write-back mode, there is data in the RAID controller’s RAM which has been acknowledged to the OS as being committed, but has not actually been committed — it must not be lost. If the system suffers a power failure, the battery in the BBU will allow the contents of RAM to remain safe, so that on restart, the RAID will be able to write that data to the actual disks.
You’ll often see a few terms:
* BBWC = Battery-Backed Write Cache — Technically refers to both the battery and the RAM. The battery is useless without RAM, but the RAM can be useful without the battery (for read caching).
* BBU = Battery Backup Unit — Sometimes refers to just the battery, sometimes the combination, as BBWC.
* TBBU = Transportable BBU — Clarifies things a bit; a BBU that is removable from the RAID card without losing its contents. This means that the battery and RAM are a single unit that can function separately from the RAID card to keep the RAM contents safe. This is often the case so that if your RAID controller itself fails (say, during a power outage), in theory the TBBU can be moved to a new RAID card along with the disks, and you haven’t lost any data.
Hope that helps!
Regards,
Jeremy
Steve,
I took a brief look at the RAMSAN. They are certainly similar in concept — basically using RAM to act as a hard drive (and look like a hard drive to the OS). The RAMSAN seems to be higher end (and higher cost).
I think the consensus is that you should just spend the money on RAM to put in your server instead of paying the premium for something like this. Still, being the benchmarking nut that I am, I would love to play with one.
Jeremy,
Thank you very much. That made everything very clear to me. I will have to check on our RAID controllers. I know they are battery-backed but I don’t know what mode they are set to currently (or if that can be changed). If we can’t do write-back with our current equipment I will make sure the next time we purchase hardware (next week actually) it has that.
I have used MySql (as well as other i/o intensive operations) on a RamSAN and can give you a bit of a clue as to performance issues. Current applications are written with the assumption that i/o takes time, once you are using a strong SSD solution that assumption is made false. If you are using a database that is receiving a high volume of input, then CPU usage will spike somewhat. Remember, on a server it is almost always assumed that the disk subsystem is the bottleneck. You are now able to keep data coming through the bus at a fast enough pace to push the CPU. When you do analysis against the database (or files) CPU usage can skyrocket and lengthy tasks can be accomplished in short order. I witnessed an efficient sorting algorithm (radix, I believe) doing 20 Million lines in a matter of seconds. RamSAN is awesome for that use.
Karl,
Thanks for the feedback. Sounds like it would be exactly as expected. Maybe one day I can convince someone to get me one
The notion that you can “just add more RAM and the problem goes away” may have worked for a read only application like a static baseball stats website but I’m working on a site which gathers a ton of user input.
In this case write performance does matter and when sustained even a write cache doesn’t matter. It would be really interesting to see what sort of performance could be coaxed from a single box with a Hyperdrive where random write performance is crucial. This is currently solved with replication and gigantic RAID arrays. I’d like to buy a hyperdrive and run some performance benchmarks some day.