CODEWITHSUNDEEP
postgresqlamazon-web-servicesamazon-ec2cpu-usagerds
Karthic Somalinga
Karthic Somalinga

Reputation: 31

High CPU Utilisation on AWS RDS - Postgres

Attempted to migrate my production environment from Native Postgres environment (hosted on AWS EC2) to RDS Postgres (9.4.4) but it failed miserably. The CPU utilisation of RDS Postgres instances shooted up drastically when compared to that of Native Postgres instances.

My environment details goes here

  1. Master: db.m3.2xlarge instance
  2. Slave1: db.m3.2xlarge instance
  3. Slave2: db.m3.2xlarge instance
  4. Slave3: db.m3.xlarge instance
  5. Slave4: db.m3.xlarge instance

[Note: All the slaves were at Level 1 replication]

I had configured Master to receive only write request and this instance was all fine. The write count was 50 to 80 per second and they CPU utilisation was around 20 to 30%

But apart from this instance, all my slaves performed very bad. The Slaves were configured only to receive Read requests and I assume all writes that were happening was due to replication.

Provisioned IOPS on these boxes were 1000 And on an average there were 5 to 7 Read request hitting each slave and the CPU utilisation was 60%. Where as in Native Postgres, we stay well with in 30% for this traffic.

Couldn't figure whats going wrong on RDS setup and AWS support is not able to provide good leads.

Did anyone face similar things with RDS Postgres?

Upvotes: 3

Views: 11134

Answers (2)

Rohini Choudhary
Rohini Choudhary

Reputation: 2473

There are lots of factors, that maximize the CPU utilization on PostgreSQL like:

  • Free disk space
  • CPU Usage
  • I/O usage etc.

I came across with the same issue few days ago. For me the reason was that some transactions was getting stuck and running since long time. Hence forth CPU utilization got inceased. I came to know about this, by running some postgreSql monitoring command:

SELECT max(now() - xact_start) FROM pg_stat_activity
                           WHERE state IN ('idle in transaction', 'active');

This command shows the time from which a transaction is running. This time should not be greater than one hour. So killing the transaction which was running from long time or that was stuck at any point, worked for me. I followed this post for monitoring and solving my issue. Post includes lots of useful commands to monitor this situation.

Upvotes: 11

Matt Beckman
Matt Beckman

Reputation: 5012

I would suggest increasing your work_mem value, as it might be too low, and doing normal query optimization research to see if you're using queries without proper indexes.

Upvotes: 0

Related Questions