Desktop HDD vs SSD for Postgresql (opens in new tab)

The first SSD tested reaches 130MB/s reading and writing. IMHO it is running in SATA-1 mode (jumper? BIOS setting?) and that's what kills its performance. Any SSD should reach a much higher read throughput.

Nowadays I use SSDs in all my home machines (MacMini, laptop, gaming desktop). It really speeded them up, since seek times are so much faster. My unix server runs with a SSD for more than a year now, and I haven't had any problems with it.

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 ;-)

I've been looking in to this recently (ref: http://news.ycombinator.com/item?id=1567330)

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 firmware needs to do clever things with caching and write combining to avoid premature wear. These algorithms are black boxes whose behaviour is very poorly modeled by the usual tuple of contiguous transfer rate / random 4K access rate / seek time etc. measured by artificial benchmarks. You don't know how the drive is really going to react until you hit it with the mix of operations that match your real workload.

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.

Not related to the article: the typography on this page gives me a headache (I'm on win7/chrome5). Ten different font size, random kerning and line space, serif mixed with sans-serif, bold/italics/bold-italics without a ratio. Argh.

Though the tests were conducted with Postgre, I suspect these results will be interesting to anyone running a database.

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.

In short -

> 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 ;)

1. You can kill a consumer-grade SSD surprisingly quickly if its being hammered with writes all day in a server. (Or at least, you can exceed the manufacturer's recommendations, and do you really want to do that in a server?)

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.

What are the implications for the web and Tim Berners-Lee's vision for linked data once the cloud switches to SSDs? Won't sites like reddit see a lot fewer problems since the DB access won't bring the hard drives to their knees?