- Newest
- Most votes
- Most comments
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:
-
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.
-
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.
-
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.
-
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.
-
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
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?
Relevant content
asked a year ago
