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
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):
|Aurora MySQL Serverless 2.07.1 4 ACU||2368||28410|
|Aurora MySQL Serverless 2.07.1 8 ACU||5835||70024|
|Aurora MySQL Serverless 2.07.1 16 ACU (192 thds)||7785||93424|
|Aurora MySQL Provisioned 2.07.1 db.r5.large||3177||38119|
|Aurora MySQL Provisioned 2.07.1 db.r5.xlarge (192 thds)||7253||87037|
|RDS MySQL 5.7.37 db.r5.large, 500GB GP2||2080||24964|
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.
- AWS OFFICIALUpdated 4 months ago
- How do I troubleshoot issues with major version upgrades in Amazon RDS for PostgreSQL and Aurora for PostgreSQL?AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 8 months ago
- AWS OFFICIALUpdated a year ago
- EXPERTpublished 2 months ago
- EXPERTpublished 7 months ago