What every programmer should know about solid-state drives
codecapsule.com
codecapsule.com
The nice thing about so much division of interest in the engineering field is that you don't always need to know everything about what's going on under the hood to use a technology to build other cool stuff. Only in specific situations is that knowledge really necessary.
Is that the case? You hear time and time again that most modern web applications in particular are I/O-bound. I suppose that depending on the particular case the I/O device in question may not be a local disk but that doesn't categorically change it.
The overwhelming majority of apps is disk I/O bound.
And most clients aren't network-bound either. They are server-bound (i.e. they spend more time waiting for the server to create a response than for the network to transfer it).
There are plenty of mobile and web apps that are network bound in this day and age. Many games, for example. That's just the obvious choice of example.
Your typical FPS shooter, RTS game or MMORPG uses bandwidth in the kbit/s range per player.
Games with a live multiplayer element certainly are. That's my meaning in saying many games (rather than most games).
That is despite using arrays of SSDs on most of our newer servers, and extensively caching things in RAM when possible.
Out of the 3,000+ servers we've managed, a very small handful are CPU bound. I/O (disk access) is almost universally the issue we work with client developers to fix, and it's extremely rare to run into anything else.
That said, I/O bound apps manifest themselves in many ways. One app could be doing something stupid with serving files, another app may have ridiculous SQL queries, another may be using the wrong technology for a given problem, etc. The universal truth though is that the CPU you toss into a server is almost inconsequential, but your RAM (read: caching) and disk configurations matter quite a bit.
Thank you for detailing this stuff. I had a quick read.
For the sake of other readers, if you don’t have time to read Part 6, here is the summary of the summary:
If you are using a decent OS like linux, as opposed to direct hardware access (who other than google ever did that?), all you need to worry about is how to co-locate your data. By “using”, I don’t mean using O_DIRECT, which basically says, “OS, please get out of my way.”
If you do use O_DIRECT, do “man 2 open” and search the man page for “monkey”. If that’s not enough, google “Linus O_DIRECT” and look at the war with Oracle and the like. You could probably also google “Linus Braindead” and you are likely to find a post about O_DIRECT.
If you are one of the few people actually working on the kernel’s disk layer, you probably know all this and is unlikely you will ever be reading this.
As for co-locating data, there is no way to do it without knowing your app inside out. So know your app. For some apps, it can make orders of magnitude difference. That’s your domain. Leave the disk to the kernel. Let it use it’s cache and it’s scheduler. They will be better than yours and will benefit the whole system, in case other apps need to get at the data too. You can try to help the kernel by doing vectorized read/writes although that’s a bigger deal with spinning disks.
Ata RoboubiI realize that's just my opinion though.
I agree. I also found the text very hard to read.
I also can't stress enough that SSDs are born for multi-threaded. If you aren't issuing multiple reads and multiple writes you are doing it wrong. If your data is sequential it is ok to send it in a single operation. If you can however issue multiple commands, do that. You'll have a better chance of getting all of them fulfilled at the same time.
It's not bad to know about, it's just another tradeoff case in storage. For scenarios that can benefit from IOPS/consistency or have huge, random loads it may be a very simple way to get a nice bump, particularly out of a "consumer" drive. For simpler loads it's a total waste versus more available storage, or even a negative if it would result in data getting pushed off of SSD onto something slower. The value also can vary from drive to drive too, so it should always get tested.
I agree with you though that the article should have mentioned that, like all tuning, there are no universals (or the manufacturer would have done it already), and that in general for modern SSDs the defaults are just fine unless you've got a specific reason otherwise (and can quantify the result). I suppose many programmers will be generating loads far higher then the typical consumer, but even so I suspect default will usually be the right choice.
Check out any of Anandtech's benchmarks from the past year or so. They now include graphs showing the consistency of I/O completion times; reserving more than the default ~7.5% makes the GC pauses a lot less severe and makes a huge improvement in worst-case performance. Under sustained load, having more spare area often makes the difference between always being stuck at worst-case performance and always being near best-case.
For example, under a solid random write workload a full Samsung 850 Pro will complete arount 7-8k IOPS, but with 25% spare area it will hover around 40k IOPS. That's a very enticing space/speed tradeoff, especially if you've already decided that SSDs are to be preferred over hard drives for your workload.
The default amount of overprovisioning in most drives is chosen to be roughly enough to allow for reasonable performance and lifespan (affected by write amplification), and in MLC drives usually corresponds exactly to the discrepancy between a binary/memory gigabyte and a decimal/hard drive gigabyte, which simplifies marketing. Drives intended for high lifespan often have odd sizes due to their higher default overprovisioning.
...because it's basically changing what the definition of "full" is.
[1] Remember this microSD article ? http://www.bunniestudios.com/blog/?p=918 I wouldn't be surprised to learn that manufacturers combine controller and over-provisioning as a cheaper and more flexible alternative to a full test of the SSD.
SSD is great because when we compile we are opening potentially hundreds of files at once. SSD is great for parallel access and blows away spinning drives.
Also, as a programmer I replace my computer every 5 years. More often than that is too much of a time sink. I may replace some parts in those 5 years. For example I upped the RAM and replaced the harddrive with an ssd on my 2009 MacBook pro. But in 2015 I purchased a MacBook pro with 16gb ram and a 1tb ssd.
as a programmer I want to focus on the programming.
Edit: sorry, I read the article but didn't quickly understand that this is a summary chapter of a book written for programmers that actually do have to worry about ssd access vs normal hard drives. It makes much more sense in this context.