Personally I've found the Intel SSDs to work best at the primary use case, speeding up small random reads, even when other drives have appeared to exceed them in random read. Bulk contiguous transfer looks really impressive, but mechanical drives with high data density are pretty fast at that too. What you really need the SSD for is random reads, and ensure that the random read performance holds up when mixed with other use patterns.
This has not been an issue for several years now. SSDs last at least as long as spinning platter disks. Especially the server-grade SSDs from the big brands. I've never heard of anyone running into this SSD wear-leveling issues in a production environment.
I don't think the wear leveling will affect the benchmarks that much though - even if it's horribly inefficient your drives will still beat the snot out of any spinning platter drive on the market today.
Just for fun, I once configured two Intel SSDs in a stripe to see how fast it would be. After tweaking the stripe block size a bit (this made a huge difference!) the stripe maxed out at 400 megabyte/sec sustained read. That's almost a CDROMs' worth of data, each second ;-)
Hmmm, since when does ~ .6 == 1? ;-)
It would be more accurate to say: "That's over half a CD-ROM's worth of data, each second ;-)"
After engineering or physics school. Try factor of 10 to get my attention :)
I just tested the speed of the elastic block storage on my EC2 instance with HDTune: http://i.imgur.com/Lbgjy.png
vs crap assed 64GB SSD I bought for my netbook last fall: http://i.imgur.com/r2eaw.png
I've been frustrated with IO speeds on EC2 the last few months, but this pushed me over the edge. I'm buying components to roll my own server.
> SSD storage devices are five to fourteen times faster than their rotational brothers using a default 8.4.X Postgresql configuration
This should've really been at the top of the article ;)
This was my first stab at Blogger as a blogging platform. The 'compose' interface was a real pain to use so I typed the whole thing in OpenOffice first. The move from OpenOffice to Blogger was not smooth thus all the weird spacing, font size changes, etc.
Also, our CSS template is sort of funky too. We are going to fix all that stuff in the next week.
This is the sort of thing that causes me to inquire about the possibility of accessing external hardware from my VPS on Linode. VPS hosts should really consider offering SSD options for a premium, IMHO.
I'd you special hardware, get a dedicated box.
If you really need super fast i/o, then why are you using a VPS in the first place? Virtualization adds a non-trivial amount of overhead to i/o, and there's really no way around that (technologies like VT-d and virtio are helping, but virtualization is still virtualization)
2. SSD should be compared to a RAID of HDDs for a realistic test
3. The article says that they want to use it to store operational stats and log files - in this case I'd spend time testing PostgreSQL's transaction and sync tunables and probably arrive at some acceptable settings which work fine on a HDD.
With this sort of workload, it is easy to make Postgres combine multiple transactions into fewer I/Os.
* By "better" I mean it performs better in the benchmarks you used. A firmware that wins benchmarks often doesn't do correspondingly well in the real world. For example, Intel's SSDs are sub-par in sequential read/write benchmarks, but they perform much better in most application benchmarks.
I'm going to guess that the second HD being tested is a OCZ Vertex LE, which is one that I have. It's a ridiculously fast SSD, however it has a lot of variance based upon the compressibility of data (as the Sandforce controller's advantage largely comes from dynamic streaming compression).