Introduction
Choose an AWS Graviton-based instance for Go garbage collection benchmarking
Install Go and Benchstat on an AWS Graviton-based Amazon EC2 instance
Create a Go garbage collection benchmark
Run the benchmark with default Go garbage collection settings
Interpret the default garbage collection benchmark results
Experiment with garbage collection optimization
Next Steps
Memory management is a critical aspect of application performance. Garbage collection (GC) plays a important role in automating memory management. GC continuously identifies and removes objects that are no longer needed, freeing memory for reuse.
This automation improves productivity and application safety. However, inefficient GC can lead to increased CPU usage, longer response times, and unexpected application pauses.
Tracking GC metrics provides a window into an application’s memory health that you can use to optimize performance and ensure the system can scale efficiently under load.
Go applications can spend meaningful time allocating memory and running GC. This makes it important to understand how the Go runtime behaves under default settings.
In this Learning Path, you’ll run Go benchmarks on an Amazon EC2 instance powered by AWS Graviton. The goal is to build a clean baseline measuring operation time, allocation rate, GC frequency, and GC pause cost.
An m8g.xlarge instance powered by AWS Graviton has enough CPU and memory to make Go runtime behavior visible, while keeping costs minimal. It’s a good starting point because it provides four vCPUs and 16 GiB of memory on AWS Graviton4.
You can use larger instances, such as m8g.2xlarge, when you want more CPU capacity or memory. Start with m8g.xlarge so the first benchmark run is easy to reproduce and inexpensive.
If you choose to run this Learning Path on a different instance, make sure it has at least four vCPUs and 16 GiB of memory to ensure the benchmark runs smoothly and provides meaningful GC metrics.
Avoid burstable t4g instances as CPU credits can affect benchmark repeatability and make GC measurements harder to explain.
Use the AWS CLI to check whether m8g.xlarge is available in your selected AWS Region, replacing us-east-1 with the Region you want to use:
aws ec2 describe-instance-type-offerings \
--region us-east-1 \
--location-type availability-zone \
--filters Name=instance-type,Values=m8g.xlarge \
--query 'InstanceTypeOfferings[].Location' \
--output table
If the command returns one or more Availability Zones, you can use m8g.xlarge in that Region.
If m8g.xlarge is not available in your Region, try a different Region, or fall back to an m7g.xlarge instance, which is based on the previous generation AWS Graviton3:
aws ec2 describe-instance-type-offerings \
--region us-east-1 \
--location-type availability-zone \
--filters Name=instance-type,Values=m7g.xlarge \
--query 'InstanceTypeOfferings[].Location' \
--output table
After selecting an instance type, launch it with the Ubuntu 24.04 LTS (arm64) AMI. You can do this using the Amazon EC2 console or the AWS CLI. When configuring the instance:
m8g.xlarge or m7g.xlarge)After the instance reaches the running state, connect to it over SSH:
ssh -i /path/to/your-key.pem ubuntu@<instance-public-ip>
You now know why measuring Go GC behavior is useful, and you’ve deployed an Arm-based Amazon EC2 instance powered by AWS Graviton.
Next, you’ll install Go and Benchstat on the instance so that you can run GC benchmarks.