- Newest
- Most votes
- Most comments
The performance issues you're experiencing with your Python scripts and RabbitMQ service are likely related to the limitations of the t2.micro instance type. This instance class is not suitable for production workloads that require high computational resources, particularly when running applications with intensive CPU requirements.
The t2.micro instance operates on a burstable performance model with only "10% CPU" as its baseline performance level, which means that once your burst credit baseline is exhausted, the instance will be throttled back down to this minimal 10% CPU allocation.
Your current performance problems are most likely caused by high CPU utilization that exceeds this 10% baseline threshold. When your Python scripts and RabbitMQ service demand more processing power than the baseline allows, the system becomes severely constrained. This situation can also be compounded by high memory usage (and OOM killer), as the t2.micro instance has limited RAM resources as well.
To confirm this diagnosis, I recommend monitoring your instance's performance through CloudWatch metrics, specifically focusing on the CPUUtilization metric. This will help you visualize whether your CPU usage is consistently above the baseline and whether you're experiencing the throttling behavior typical of burstable performance instances when they exceed their allocated burst credits.
There are several potential reasons why your EC2 t2.micro instance running Windows with Python scripts and RabbitMQ is experiencing extreme slowness:
-
CPU Credit Limitations: T2 instances like t2.micro use a credit-based system for CPU performance. They have a baseline CPU performance and can burst above that baseline by consuming CPU credits. Once these credits are depleted, the instance's CPU performance drops significantly to the baseline level, causing slowdowns. Your Python scripts and RabbitMQ may be consuming more CPU resources than the baseline allows.
-
Memory Constraints: The t2.micro instance only has 1 GB of RAM, which is quite limited for running Windows, Python scripts, and RabbitMQ simultaneously. When the system runs out of memory, it starts using swap space on the disk, which is much slower and can cause the system to appear unresponsive.
-
Instance Type Limitations: T2.micro instances are designed for very light workloads or proof of concept deployments, not for running multiple services or resource-intensive applications.
-
Network Throttling: If your scripts involve significant data transfer, you might be experiencing network throttling. T2 instances have limited network bandwidth, and extended high usage can lead to performance degradation.
To address these issues, consider:
-
Upgrade to a Larger Instance: Consider upgrading to a larger instance type with more CPU and memory resources, such as a t3.small or t3.medium.
-
Enable Unlimited Mode: If you haven't already, enable unlimited mode for your t2.micro instance. This allows it to burst beyond the CPU credit balance (though at additional cost).
-
Monitor Resource Usage: Use Windows Task Manager or AWS CloudWatch to monitor CPU, memory, and network usage to identify specific bottlenecks.
-
Optimize Your Code: Review your Python scripts for inefficiencies, unnecessary computations, or memory leaks that might be causing high resource usage.
-
Consider Graviton Instances: If eligible, you might benefit from the Amazon EC2 T4g Free Trial, which includes t4g.small instances (2 vCPUs/2 GB RAM) through December 31, 2025.
Remember that while these steps may help improve performance, a t2.micro instance may simply be too small for your workload, especially when running on Windows, which typically requires more resources than Linux.
Sources
Extremely Slow/Stuck Ubuntu on EC2 (t2.micro) | AWS re:Post
T2 micro unlimited | AWS re:Post
EC2 Instance Network Throttled? | AWS re:Post
t2.micro crashing whenever I access with VScode | AWS re:Post
Ec2 Instance on Windows | AWS re:Post
t2.micro are not powerful and you are running windows on it. It could be out of credits besides having low CPU and RAM. I reckon you need to upgrade the instance.
Also, if you must use smaller EC2s due to budget, you can configure SQS queue instead of using RabbitMQ. With SQS queue, you don't need to configure the compute and only for use. Thus, you can still remain in budget.
Relevant content
- asked a year ago
- asked 3 years ago
- AWS OFFICIALUpdated a month ago
