AWS t2.medium performance issues after adding 32 gb volume

1
votes

On AWS EC2 t2.medium instance we run a site http://www.pricesimply.com/

Our database is installed on the same machine. By default we had 8 gb storage and the site speed was lightning quick.

Then, we added a 32 gb volume Type - general purpose volume.

Only difference between these 2 volumes -

8 gb default volume - IOPS 24/3000

32 gb new added volume - IOPS 96/3000

Volume type & Availability zones are same.

The site MUCH SLOWER now compared to earlier.

2
amazon-web-services
What is the CPU credit balance? Are you I/o bound? - tedder42
CPU credit balance has an average Value : 430 (Count) - Rohan Chopra
Drupal is deployed on the server. Caching, database logging take place. How can I find out whether we are i/o bound ? - Rohan Chopra
Look at iostat or the cloud watch stats related to disk. - tedder42
There are 16 ebs volume parameters. VolumereadOPs and VolumeWriteOps are between (Count) 15000 to 25000 - Rohan Chopra

2 Answers

2
votes

Some random ideas:

1) Performance does vary between volumes. Do some benchmarks to see if it's really slower. (Unlikely, but possible.)

2) Perhaps the volume is a red herring -- Maybe your entire dataset was small enough to fit into RAM before, and now that you've expanded and grown, your data doesn't fit, creating constant I/O?

3) If the drive was created from a snapshot, it may be fetching your data from your snapshot in the background, slowing the drive.

1
votes

Adding an additional disk shouldn't slow down your machine, you'll need to investigate things a bit more to identify the bottleneck.

Poor performing infrastructure generally fits into one of three categories:

  • CPU: Check your CPU utilization to see if the t2.medium instance is a suitable size. Amazon CloudWatch can show you CPU history.
  • Memory (RAM): Your application may be short on memory, causing page swaps to disk. You'll need to monitor memory utilization from within your instance. (CloudWatch cannot see memory utilization.)
  • Disk IO: If you are reading & writing to disk a lot, then this could be your bottleneck. CloudWatch can give you some metrics, especially the Queue Length, which indicates that IO was waiting to be processed.

Once you've identified which of these three factors appears to be the bottleneck, try to improve them:

  • CPU: Use a larger instance type
  • Memory: Use an instance type with more RAM
  • Disk: Use a faster disk

You are using General Purpose (SSD) EBS volumes. These volumes have an IOPS (Input/Output per second) related to volume size. So, your "96/3000" volume gives a guaranteed 96 IOPS (about the speed of a magnetic hard disk) with the ability to burst up to 3000 IOPS if you have enough IO 'credits'. If you are continually using more than 96 IOPS, you will run out of credits and will be limited to 96 IOPS.

See: Amazon EBS Volume Types