By using AWS re:Post, you agree to the Terms of Use

poor MariaDB RDS gp2 storage volume write performance?


I am seeing what I think is very poor write performance with a 100 GiB gp2 SSD RDS storage volume (RDS MariaDB 10.5.12 Multi-AZ db.t4g.large).

From reading this blog, I should see around 30 minutes of 3000 IOPS using the burst balance, if I am am able to drive it that fast. However, I never see that.

The best I've seen is around 450 write IOPS. I changed the volume type to an io1 with 3000 IPOS provisioned, just to compare, and I was seeing up to 3000 IOPS with that volume, with everything else the same.

During the tests with the gp2 volume, RDS CPU never got above about 13%. Binary log disk usage rose to a ceiling of around 48 MiB - I guess this is required by the Multi-AZ replication (??). Write throughput was no more than about 2 MiB/s. The EBS IO Balance %age barely moved below 100%. All in all, the RDS instance looked almost idle.

Am I making an incorrect assumption somewhere, or do you think I have a faulty gp2 volume, if that is even possible?

Thank you

1 Answer

TL; DR - there is no SLA for IOPS. The EBS SLA is for availability, and the SLA is not relevant for a single EBS volume.

Please refer to the Compute SLA which states that..

“Unavailable” and “Unavailability” mean:

For the Region-Level SLA applicable to Amazon EBS, when all of your attached volumes deployed in two or more AZs in the same AWS region (or, if there is only one AZ in the AWS region, that AZ and an AZ in another AWS region) perform zero read write IO, with pending IO in the queue.

This document states that..

AWS designs gp2 volumes to deliver their provisioned performance 99% of the time.


Provisioned IOPS SSD volumes use a consistent IOPS rate, which you specify when you create the volume, and Amazon EBS delivers the provisioned performance 99.9 percent of the time.

Practically speaking, a gp2 volume can provide 1 IOPS (by definition still available, since the definition of unavailable is "zero read write IO") for up to 7 hours in a month (1% of 730 hours) and still meet design parameters. An io1 volume, meanwhile, could display IOPS reduction for up to 0.73 hours in a month and still meet the design parameters.

Also note that the statement on ".. provisioned performance 99% of the time" is with respect to the 3 IOPS per GB. The 3000 IOPS burst has no such statement.

If you need better IOPS consistency then io1 is an option, you must weigh the cost of this versus the IOPS that your application requires.

A cheaper work-around is to over-provision your gp2 storage, giving you more provisioned IOPS (and generally the cost would still be lower than using io1). You may want to provision 500GB of storage.

answered 6 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions