5

I have hosted an e-commerce site in AWS-EC2 in a t3a.medium instance type. Now that the traffic is increasing CPU utilization is very high and site stops working time and again. Looking into htop, mysql is utilizing maximum CPU.

As in the current instance, vcpu is only 2 so I want to change the instance type. But the problem is how do I know which would best fit my system?

7
  • One of the advantages of GCP over AWS is that you get flexibility in memory and CPU sizes instead of being locked into pre-defined instance sizes.
    – chicks
    Sep 15, 2020 at 19:17
  • What about cpu credits?
    – ALex_hha
    Sep 15, 2020 at 19:39
  • @chicks true, but there are a lot of instance options, its a matter of finding a useful+affordable one.
    – Criggie
    Sep 15, 2020 at 21:00
  • If MySQL is bottlenecking your EC2 instance, you might be better served by replacing it with an RDS instance - which is specifically designed for this workload. At your scale, you might be even better served by a shared hosting account from HyperNode, MageMojo or even GoDaddy/BlueHost/etc.. Sep 15, 2020 at 22:08
  • 1
    This URL does not indicate t3a.medium is reasonable for high utilization. aws.amazon.com/ec2/instance-types/t3 Move up in the world to something more powerful for your peace of mind and serving your customers with a 'working system' all the time. Sep 19, 2020 at 0:33

3 Answers 3

29
  1. It's easy to change the instance types up, down, or sideways. Don't try to guess which one will work the best for you - instead test it out. If you've got t3a.medium now try upgrading to t3a.large. Or to m5.large - it may be cheaper if you're maxing out the t3a.large and constantly running out of CPU credits (check the monitoring tab in the instance details).

    If your app is memory-hungry look at r5.* instances, if it's cpu-heavy look at c5.* instances. They tend to be cheaper than the general purpose for some workloads.

  2. Best practice is to decouple your database from your app/web frontend, don't host them on the same instance. Move the database to AWS RDS service - it will manage it for you, including backups, upgrades, fail over, etc.

  3. Once your app is decoupled from the database look at Auto-Scaling - instead of upgrading to a larger and larger instance as your traffic grows you can scale horizontally by adding more and more smaller instances, all configured the same. That allows you to run with fewer instances in quiet times (night, weekends) and add more of the same in busy times. That way your per-hour bill will fluctuate with the traffic load.

The bottom line is that there is no "best EC2 instance" - it all depends on your actual usage.

The good thing is that there is no long-term commitment in AWS, simply test things out and evolve the architecture as needed.

Hope that helps :)

4
  • 1
    Of course, the followup question would be: How to choose best RDS instance for the system But moving RDS to a higher level when needed is a bit easier than moving EC2, plus you can get multi-AZ at 2x cost but with zero configuration/management work. Sep 15, 2020 at 14:23
  • 1
    Another question: what is really burning up the mysql? Maybe the query pattern can be optimized and the current instance/setup will keep working. Moving to RDS is smart if you're going to stay within AWS and I would do that first since it is pretty easy. You might still need to add some indexes or optimize the app to be efficient-enough for your request volume. There's no reason to pay AWS for a bigger RDS than you have to.
    – chicks
    Sep 15, 2020 at 19:23
  • Regarding your last point, AWS Reserved Instances offer substantial savings if you commit to leasing hardware for at least a year. OTOH being semi-locked in to specific VM sizes means their use is a lot more appropriate for cases where you don't anticipate any scaling needs (eg devops infrastructure), or can easily auto-scale more capacity as needed (eg baseline web server capacity); but not anything that can't easily scale to multiple instances (databases, server software with non-trivial install processes). Sep 16, 2020 at 11:14
  • Excellent answer, I would add: There is normally no reason to choose an instance of a previous generation, ie. t2, c4, m4 etc. Secondly, Savings Plans are a good replacement for reserved instances now as they offer much more flexibility, even when moving to containerization or serverless
    – jdog
    Sep 17, 2020 at 1:36
4

Additionally, there's a great comparison site at https://www.ec2instances.info/ to help you decide which instance-type is most cost-effective for your needs.

Simply going up an instance size might not be suitable for your need or budget.

You can see from your own monitoring that the host is capped on CPU - either use internal tools, or the AWS monitoring tab in EC2. Note EC2 doesn't show Memory usage, you'll have to get that info from your own tools.

So the site above (which is not official AWS) lets you pick a minimum CPU and Mem, and then sort on cost. Note that pricing varies across AWS DCs, and that displaying price "monthly" is easier to comprehend than per-hour pricing.


Also, instance types that start with T (that is, t3, t2, t4g instances) all use "CPU Credits" So you don't get to use the cores at 100% all day. The amount of CPU is based on a bucket that you can drink from, but slowly refills.

Screenshot of own work

You can choose to turn on "Unlimited CPU" for T* instances, but this costs quite a lot, and doesn't take much before moving to a dedicated CPU instance like a M5 becomes cheaper.


EXAMPLE

For you, a t3a.medium has 4GB ram and 2 vCPUs for 4h 48m a day for $35 US/mo

Turning on Unlimited CPU could increase that to approx $80/mo at 100% usage.

A c5a.medium is the same spec, but has CPUs for 24 hours a day for $65 US/mo

If you need more CPU, a c5a.xlarge gives 8GB and 4vCPUs for $129 US/mo.

Notes:

  • those prices are for the Singapore DC. Others vary.
  • Instance types with "a" in the third position are AMD Epyc based. That may or may not suit your need. Those with "g" are Graviton2 based which are ARM-64, and those that start with "a" are older Graviton instances. Confused? D means disk and N means faster network.

enter image description here

1

We experienced similar difficulties with EC2 t3a instance types (t3a.medium) with MySQL Server 5.7.32. The CPU usage would be 100% all the time. Switching to t3 instance fixed our problem.

Maybe and I say maybe, MySQL is not optimized for T3a instances (AMD EPYC).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .