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

Aurora Compute Units (ACU) benchmarks

0

Is there any guidance on how many reads / writes are typically supported by 1 ACU for PostGres engine. We need this info for cost-estimation and capacity planning reasons. #AuroraServerless

asked 6 months ago684 views
1 Answers
1

AWS will not provide benchmark results, because every customer's workload is different. Also, the mapping of ACU to performance will change because AWS continuously iterates to improve its services, leading to changes in the underlying implementation (e.g. move from Intel to AMD or ARM).

This document for Aurora Serverless here - https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.how-it-works.html

States that

Each ACU is a combination of approximately 2 gigabytes (GB) of memory, corresponding CPU, and networking.

Aurora Serverless v1 manages the warm pool of resources in an AWS Region to minimize scaling time. When Aurora Serverless v1 adds new resources to the Aurora DB cluster, it uses the router fleet to switch active client connections to the new resources.

The appropriate approach to determine "performance per ACU" is by benchmarking, e.g. using sysbench. Please refer to this blog post for how to proceed: https://aws.amazon.com/blogs/database/running-sysbench-on-rds-mysql-rds-mariadb-and-amazon-aurora-mysql-via-ssl-tls/

I did a quick sysbench run using a 5.8GB data set (100 tables, each of 250K rows) with the oltp_read_only.lua benchmark. Note that these results are not in any way "official" numbers or validated by AWS. Also, these results are for Aurora MySQL, but a similar approach should work for Aurora PostgreSQL, and are "quick and dirty" - a rigorous benchmark would have dozens or hundreds of test runs for each test case, to quantify variability.

With this data size, the entire data set fits in memory and there is no IO bottleneck since the benchmark is all reads, so this is primarily a CPU/memory benchmark.

The following command was used to create the sample data (the assumption is an "sbtest" database has already been created):

sysbench /usr/share/sysbench/oltp_read_write.lua --threads=32 --mysql-host=XXXX.ap-southeast-1.rds.amazonaws.com --mysql-user=XXX --mysql-password='XXX' --mysql-port=3306 --tables=100 --table-size=250000 prepare

The load test was then run using an m5.2xlarge EC2 instance (8 vCPU, 32GB RAM) as the load generator, with the following command:

sysbench /usr/share/sysbench/oltp_read_only.lua --threads=96 --events=0 --time=600 --mysql-host=XXXX.ap-southeast-1.rds.amazonaws.com --mysql-user=XXX --mysql-password='XXX' --mysql-port=3306 --tables=100 --table-size=250000 --range_selects=off --db-ps-mode=disable --report-interval=10 run

Here are my results (note that I had to increase the number of connections/threads to 192 in some of the benchmark runs):

ConfigurationTPSQPS
Aurora MySQL Serverless 2.07.1 4 ACU236828410
Aurora MySQL Serverless 2.07.1 8 ACU583570024
Aurora MySQL Serverless 2.07.1 16 ACU (192 thds)778593424
Aurora MySQL Provisioned 2.07.1 db.r5.large317738119
Aurora MySQL Provisioned 2.07.1 db.r5.xlarge (192 thds)725387037
RDS MySQL 5.7.37 db.r5.large, 500GB GP2208024964

There appears to be a scaling inflection point between 8 ACU and 16 ACU; I have also seen this with provisioned Aurora at large instance sizes.

As always, YMMV. A more realistic benchmark that includes inserts, updates, and deletes (e.g. sysbench oltp_read_write.lua) should be executed, to investigate IO performance.

answered 5 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