Skip to content

CPU sizing issue

0

This issue has come up because I need to create an alarm to shut down the instance when it is not being used, typically based on CPU utilization. I am running SQL Server on an EC2 instance with maybe 10 users querying it at one time. I've followed right sizing recommendations and am now using M7iFlex.Xlarge (4 CPU/16gb) the instance settings are now telling me I am undersized for CPU again and recommending a larger instance type for more CPU. However, when I open the monitor for the instance, the average CPU usage throughout the day is in the 20-25% utilization range, it is my understanding that should be closer to 80%. The right sizing graph shows a lot of spiking which could be triggered by database backups and exports, not sure. Given that it is hard to create an alarm for cpu utilization when so little cpu is being used I'm wondering whether I should downsize my instance type versus the recommendation to upsize it. Thanks.

asked 2 years ago272 views

2 Answers
0

Based on the information you've provided, it seems there's a discrepancy between the right-sizing recommendations and your actual observed CPU utilization. This is a common scenario, especially with database workloads that can have periodic spikes in activity.

Given that your average CPU usage throughout the day is only 20-25%, you are correct in thinking that this is quite low. Typically, for cost-efficient usage, you'd want to see utilization closer to 80% as you mentioned.

The recommendation to upsize might be based on those CPU spikes you're seeing, which could be caused by database backups, exports, or other periodic intensive operations. However, if these spikes are short-lived and don't represent your normal workload, upsizing might not be the most cost-effective solution.

Instead of upsizing, you might consider the following options:

  1. Monitor your workload more closely to understand the nature and frequency of those CPU spikes. If they're infrequent and short-lived, your current instance size might be appropriate.

  2. If you decide to create an alarm to shut down the instance when not in use, you could set it based on a longer period of low CPU utilization, rather than reacting to short-term fluctuations.

  3. Consider using a smaller instance size if your average utilization remains low. You could test this by temporarily downsizing and closely monitoring performance to ensure it meets your needs.

  4. Look into using AWS Auto Scaling with a target tracking policy. This could automatically adjust your instance size based on CPU utilization, scaling up during peak times and down during periods of low usage.

  5. Investigate if there are any optimizations you can make to your SQL Server configuration or queries to reduce the CPU spikes.

Remember, while AWS provides recommendations, your specific use case and requirements should guide your decision. If the current performance meets your needs and you're not experiencing issues, downsizing could be a valid option to explore, especially given the low average CPU utilization you're observing.
Sources
Govern Microsoft workloads using the myApplications dashboard on AWS | Microsoft Workloads on AWS
AWS AutoScaling group created many more instances than the configured max capacity. Why? | AWS re:Post
AWS EC2 Auto-Scaling and CloudWatch Alarm Trigger | AWS re:Post

answered 2 years ago

EXPERT

reviewed 2 years ago

0

There are few things you can check

  • Is your CloudWatch monitoring detailed or default monitoring? With detailed monitoring you can see monitoring at the minute level instead of the 5 minute level which might be hiding the spikes.
  • Sql Server, from experience, is memory heavy and not CPU heavy. I would suggest monitoring for memory as well and see if you have spikes?
  • Also, why don't you move to RDS? Is it licensing issues?
EXPERT

answered 2 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.