AWS RDS Support
Fix AWS RDS high CPU and slow queries.
High CPU on RDS is usually a symptom of a few expensive queries, missing indexes or a connection storm, not a sign that you need a bigger instance. We use database load data to find the exact statements and waits, fix them, and only then decide whether to resize.
When You Need This
The situations where this work pays for itself.
Signs it is time
- CPUUtilization sits near 100 percent on an RDS instance
- Application latency rises at predictable times
- A new release made the database slower
- Read latency is high even though traffic is flat
- You are about to scale up the instance and want to avoid paying for a fix a query change would make
What you get
- Top queries ranked by load with explain plans and fixes
- Index and query changes with before and after database load
- Slow query logging and Performance Insights retention configured
- A sizing recommendation based on measured load
How we do it
A clear, safe process you can follow along with.
1. Confirm the symptom
We compare CPUUtilization, DatabaseConnections, ReadIOPS and WriteIOPS in CloudWatch over the incident window and check whether CPU rises with traffic, with a deployment, or with a scheduled job.
2. Open Performance Insights
Database load shows average active sessions against the instance's vCPU count. Load above the vCPU line means sessions are queuing. We slice it by SQL, wait event, user and host to see who causes it. Check how your console presents Performance Insights, since AWS is folding it into CloudWatch Database Insights.
3. Read the waits
CPU waits mean real compute work. IO waits point to missing indexes or undersized memory. Lock waits point to contention in transactions. Each needs a different fix.
4. Find and test the worst statements
We take the top SQL, run EXPLAIN (or EXPLAIN ANALYZE where safe) and look for full scans, bad join order, missing or unused indexes, and functions applied to indexed columns.
5. Use engine tools for more detail
We enable the slow query log or log_min_duration_statement through the parameter group, and on PostgreSQL use pg_stat_statements. Enhanced Monitoring shows if the OS or a single process is the source.
6. Fix, then verify
We add or change indexes, rewrite queries, cache hot reads or add a read replica for reporting. After each change we compare database load and latency, rather than only CPU.
7. Decide on instance size last
If load remains legitimate after tuning, we right-size the instance class, including a Graviton-based class where the engine supports it.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Scaling up first
A bigger instance hides a bad query until the data grows. We fix the query and then size.
Adding indexes blindly
Extra indexes slow writes and use storage. We add only those the plans justify.
Ignoring connection counts
Hundreds of active sessions on a small instance burn CPU on context switching. A pooler or RDS Proxy may be the fix.
Running analysis only in a quiet hour
Problems show during peak load. We capture data during the actual incident window.
Frequently Asked Questions
Why is my RDS CPU at 100 percent?
Typical causes are a few expensive or unindexed queries, a spike in concurrent connections, a runaway job or an undersized instance. Database load by SQL statement pinpoints which.
How do I enable the slow query log on RDS?
Set the relevant parameters in a custom parameter group, such as slow_query_log and long_query_time on MySQL or log_min_duration_statement on PostgreSQL, then publish logs to CloudWatch if wanted.
Does Performance Insights cost extra?
A free retention tier is available and longer retention is billed. Check current pricing and the retention options for your engine and console.
Want Help With Fix AWS RDS high CPU and slow queries?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required