Tag Archives: AWS

Adding Swap Space to an AWS EC2 Micro Instance

I recently moved some of the WordPress sites on an EC2 m1.small instance in Amazon Web Services (AWS) Singapore data centre to a m1.micro instance in the new Sydney data centre. Unfortunately the new t1.micro instance has run out of memory a couple of times, resulting in the websites being unavailable. After I was notified I had to find out what process/service was killed and restart it.

To stop this happening I could either upgrade to a m1.small instance with 1.7 GiB instead of the 613 MiB, or I could add swap space to the existing server.

I decided to try and save some money by adding swap space to my existing server. There are two main options to do this:

  1. Create an EBS volume and dedicate it to swap space.
  2. Create a swap file on the existing file system (also an EBS volume if you are using an EBS based AMI).

If you decide to add an EBS volume then the smallest size is 1 GB, for which you will have to pay the prevailing monthly rate in the AWS region of your instance. Make sure you put the EBS volume in the same availability zone as your instance or you will not be able to attach it! You will also be charged the I/O costs as data is written to and from the swap space.

With a swap file you only get charged the I/O costs, since you are already paying for the empty space. I still had quite a bit of space available and thought that 512 MB of swap space would be sufficient, so I chose this method.

I’ll describe what I did first and then outline the option using a dedicated EBS volume.

Adding a Swap File

First of I needed to decide where to put the swap file and what to call it. I chose /mnt/swap_512.swap and created it with the following command:

dd if=/dev/zero of=/mnt/swap_512.swap bs=1M count=512

Next I needed to let Linux prepare the file for use as a swap file by using the mkswap command:

mkswap /mnt/swap_512.swap

Finally, I activated the swap file with the swapon command:

swapon /mnt/swap_512.swap

You can check to see if your swap file is being used with top or free. Here is the output from free on my machine:

             total       used       free     shared    buffers     cached
Mem:        615664     592288      23376          0       8548     144448
-/+ buffers/cache:     439292     176372
Swap:       524284        348     523936

You should edit your /etc/fstab file to add the swap file information so that it is available if you restart the instance. This is what my fstab looks like on my t1.micro instance:

LABEL=/     /           ext4    defaults,noatime  1   1
tmpfs       /dev/shm    tmpfs   defaults        0   0
devpts      /dev/pts    devpts  gid=5,mode=620  0   0
sysfs       /sys        sysfs   defaults        0   0
proc        /proc       proc    defaults        0   0
/dev/sdf    /u01        ext4    defaults        0   0
/mnt/swap_512.swap swap swap    defaults        0   0

Note that I have another EBS volume attached for backup purposes that is mounted at /u01.

Adding a Dedicated EBS Volume for Swap Space

First you’ll need to create a new EBS volume in the same region and availability zone as your t1.micro instance. The smallest size is 1GB, which should be more than enough for your swap space.

Once the volume is available you need to attach it to your instance and then note the device so that you can refer to it later. For example, my backup volume is /dev/xvdf with a link to that called /dev/sdf.

There is no need to create the file like the previous example, so you can go straight to preparing the device for use as swap space with the following command:

mkswap -f /dev/xvdf

The -f will force the use of the whole disk, which is what you want.

You can then activate the swap space with:

swapon /dev/xvdf

Again you should edit your /etc/fstab to make sure the swap space is available upon a reboot. Just use my example above, replacing the /mnt/swap_512.swap with /dev/xvdf or your assigned device.

Conclusion

Adding swap space to your AWS EC2 micro instance is quite a simple process that can bring much needed stability (random process kills to keep the machine running are not fun). It can also give you time to catch a memory hogging process before it brings the machine to a halt. However, you do need to monitor your swap usage. If you find that your system is constantly reading and writing to swap then your system’s response time can slow down dramatically. In this case you are truly memory bound and need to upgrade to an m1.small instance.



Singapore Broadband Internet Plan Speed Comparison

A fellow forum user, Sunblock, of Xtremeplace.com wrote a post asking about FTP performance with broadband internet fibre plans compared with his existing Starhub Cable 100Mbps plan. I thought that it would be interesting to do a realistic comparison, so I offered to set up a server to allow us to run some performance tests.

I’m on Starhub’s Maxinfinity 100Mbps fibre plan which I find to be quite fast and reliable. I asked for other users who are on M1 or Singtel to join our testing session and received one reply for each service. I also asked a couple of people who were on Starhub’s Maxonline cable plan to run some tests too.

Test Environment

The main objective was to determine the advantage of one plan over another for FTP usage from Singapore to the USA. The easiest and cheapest way I know to get a server in the USA is to use Amazon Web Services (AWS), so I set up a “small” instance running Amazon Linux in the US West region.

After logging on to the server I ran a system update to make sure everything was up to date. I also installed Apache and vsftpd for HTTP and standard FTP testing. A 100MB file was uploaded to the server and placed in the correct directories for HTTP, FTP and SFTP testing.

Finally, I distributed the key files to the testers to enable SSH and SFTP connections.

Tests

1. Download 100 MB file via SFTP.

2. Download 100 MB file via FTP.

3. Download 100 MB file via a web browser (HTTP).

Results

Plan SFTP FTP HTTP
Starhub 100Mbps Cable 320 KB/s 370 KB/s 50-80 KB/s
Starhub 100Mbps Fibre ~300 KB/s 239-255 KB/s 2.50-6.4 MB/s
M1 50Mbps Fibre 220 KB/s N/A 70 KB/s – 1.4 MB/s
Singtel 200Mbps Fibre 450 KB/s N/A 300 KB/s
Starhub 100Mbps Cable N/A N/A 50-70 KB/s
AWS Singapore 2.3 MB/s N/A 2.47-2.6 MB/s

Note: The upload speed via SFTP was 254 KB/s from my home PC running Filezilla. FTP tests were added at a later time, so only two people completed them.

Running through the results:

Sunblock’s 100Mbps Maxonline Cable plan offers consistent SFTP and FTP performance, but the HTTP performance is simply shocking.

My own Starhub Maxinfinity fibre plan offers consistent SFTP and FTP performance, but screams along for HTTP. In fact the 2.50 MB/s was a one off and all the other tests were in the 6 MB/s range. I thought that this could be due to some local caching, but then surely the cable plans would also get this benefit.

The M1 fibre plan has the slowest SFTP performance and can get up to reasonable HTTP speeds, but seems rather inconsistent.

Singtel’s 200Mbps fibre plan offers the best SFTP performance amongst the local providers, but it’s still not fantastic. The HTTP performance is poor in comparison with the other fibre plans.

To confirm Starhub’s abysmal HTTP performance on its cable plans I contacted two other people who both averaged 50-70 KB/s.

My AWS server in Singapore (micro instance), returned a healthy SFTP result, but couldn’t match my own HTTP performance on Starhub’s fibre plan which I was quite surprised at.

Conclusions

Given the huge difference between the SFTP result on my AWS server in Singapore and all other tests I am guessing that the local ISPs are engaging in network shaping for both SFTP and FTP. This is also reinforced from running the SFTP test repeatedly and seeing  close to 300 KB/s each time on my own computer.

HTTP performance on the other hand shows dramatic differences across technologies and providers. Starhub’s cable plans have terrible HTTP performance, while their fibre plan is great. Singtel’s performance was particularly disappointing, especially given it is from a 200 Mbps plan.

In the end there doesn’t seem to be much point for Sunblock to move to a fibre based plan from any of the local providers. His cable plan performs within the same range or better than the fibre plans for FTP, which is his main concern.