kriston's Journal: Optimize performance of EC2 EBS volumes and Amazon WorkSpaces

Amazon EC2 and Amazon WorkSpaces are very handy. Unfortunately, the first time you bring up any new instance the performance starts slow and improves over time. This is apparent when creating any new EC2 instance on EBS, when creating a new EBS volume from a snapshot. This includes creating an AMI and also copying volumes to other Availability Zones.

The culprit is Thin Provisioning. The EBS volume is only allocated physical space when it's needed. This is fine for Amazon but not so fine for your performance. There is an easy to to remove this millstone from around the system's neck but it will take some time and may cause network charges to do so. It's well worth it if you plan to use the system for regular work, and especially if you use Amazon WorkSpaces as one of your daily desktop environments.

My examples use the "dd" command in Cygwin or Linux. In Windows you can use Cygwin or search for the various dd.exe commands available on the internet.

On a brand-new Amazon WorkSpaces instance, see how much space is free on your "C:" and "D:" drives. On a regular EC2 instance, see how much free space is on all your drives (you will know this already). Write these values down.

Start a shell (or Cywgin shell as Administrator) and do the following. Note that if you're using dd.exe without Cygwin it's up to you to figure out what the "if" parameter would be.

dd if=/dev/zero of=./datafile-40gig.dat bs=10M count=4096
Check how much data is free:
df -kh .
Then repeat the "dd" command again with new values to fill the remaining data.

In this particular example my volume had a little over 40 gigabytes free so I'm creating a file of 40 gigabytes in size. The block size is kept at 10 megabytes. You can fine-tune this but in my experience nearly any values that add up to 40 gigabytes takes the same amount of time to complete.

Of course, when these complete, don't forget to delete the files.

That's it. You don't need to reboot. Thin provisioning has been defeated and you can enjoy better performance on your EC2 and Amazon WorkSpaces instances.

Note: In Windows you could theoretically create a new paging file of 40 gigabytes but I have not been able to prove that Windows actually writes 40 gigabytes to disk or just allocates the 40 gigabyte space as in-use. I suspect the latter, in which case it does nothing to improve performance.

This process can be used on any other storage architecture, virtual machine or not, that is configured to use Thin Provisioning. If you suspect shenanigans are happening in which the storage system knows you're just writing zeroes and defeats you, you can use /dev/random to counteract and force physical alocation. It will take far longer to write the data file, however.