Maximum Random Disk I/O Performance

Linodes are provisioned homogeneously on host boxes; a host server will only ever have multiple 512s, or multiple 1024s, or multiple 2048s, etc. They will never mix and match.

Linode keeps hardware details close to the chest, but we do know that they use 4-drive 15K RPM SAS drives in RAID10 as the storage solution, and we (the customer base) believe this to be true for all linode host hardware, of any size.

The advantage you get from larger linodes is that you get a bigger share of the pie. A while ago, the supposition was that there were 24GB of RAM in host machines, with 20GB usable. I don't know if this is still true today (probably not, the 20GB figure was from a few years ago, if memory serves), but if we go by this for our example, then there are 40 linode 512s on a box, 20x 1024s, 10x 2048s, and so on. So, the bigger the linode you get, the bigger the share of IO, and the less contention from other people. But the 20GB figure is probably not true anymore. There have been at least one linode RAM upgrades since then, for example.

Anyhow, in terms of the performance on a 512, it should still be very good, it's possible that you hit a box with high contention. You can open a trouble ticket and have them check the host IO to see if you might need to have your linode moved to another box. You can also try a larger linode (they're pro-rated to the day, so a day of testing on a 4GB linode would cost roughly five bucks). Beyond that, I guess the standard DB optimization strategies would apply; more RAM for caching, make sure you're indexing properly, memory tables for low-value but high-IO data, database clustering across multiple machines, etc.

In terms of fake RAID, you can do that with multiple linodes if you'd like. I'm not an expert in this kind of stuff, but the first thing that comes to mind would be RAID10 over iSCSI. Get a few storage linodes, use them to host one iSCSI target each, and on the database machine, RAID the iSCSI targets together. I'd be worried about doing RAID between multiple machines in terms of maintaining consistency in the face of potential failure, but you could do it. However, it seems to me like the correct approach would be to do the clustering on the database level rather than the storage level.

Like all IO, some optimisation can be achieved by choosing a filesystem like XFS that has less IO (LInux Conf 2012 XFS talk). IO can also be reduced using mount -o noatime.

You may of considered this but I though I'd mention it. I've also needed barrier=0 in Linode 3.* kernels when mounting XFS filesytems.

XFS lost most of the performance advantages to ext4, and has a bunch of other annoying limitations, such as the inability to be shrunk, which is a pretty major issue on a provider like Linode where resizing disk images for linode resizes or migrations or backup restore isn't uncommon. Basically, there doesn't seem to really be any reason to use XFS anymore, since most of its real advantages over other file systems no longer exist.