Introduction:

Databases are typically the crown jewel of enterprise applications. All workloads including web-based e-commerce, social media, cloud services are typically backed by a database. Open-source databases[i] have become completely mainstream over the past decade and are the primary leaders in innovation in the database space. Open-source software has many attributes that make them successful in this cloud era. One of the major benefits is that developers can use open-source software and databases, without any licensing fees. Open-source software as developers code in features that they need quickly and contribute it back to the community. Open-source projects are therefore more agile and have out-evolved closed source alternatives since the early 2000s. 

AWS is positioning Graviton (an ARM based processor) aggressively from a price perspective compared to Intel 3^rd generation Xeon Scalable Processors based instances.[ii] They are using cost savings as the primary mechanism to lure customers away from Intel based instances. Re-platforming is needed for customers moving to Graviton, which requires enterprise re-certification of the software with associated porting cost.  Intel Xeon leads across most popular database, web, and throughput related workloads. The cloud ecosystem for Intel has developed over the past 15 years, whereas ARM is relatively new and untested. Customers can potentially experience cloud vendor lock-in as Graviton is unique to AWS.

The critical nature of open-source databases in the cloud makes them a good workload to compare Amazon EC2 Intel 3^rd generation Xeon Scalable and Graviton instances. MariaDB[iii]  is an open-source variant of MySQL that offers a consistent set of advanced features and functionality across all major cloud platforms. PostgreSQL is one of the most powerful open-source databases known for its proven architecture, reliability, data integrity, robust feature set and extensibility. We will use MariaDB and PostgreSQL as the two open-source relational databases used in comparison testing on AWS EC2 between Intel 3^rd generation Xeon Scalable processors and Amazon Graviton.

Amazon RDS:

The Amazon Relational Database Service (Amazon RDS) is a collection of managed services that makes it simple to set up, operate, and scale databases in the cloud.  Amazon RDS is used in modern applications for data storage in web and mobile applications. Customers move to managed databases from RDS to avoid having to manage their own databases. Many customers want to leverage open-source databases in the public cloud and break free from legacy databases

MariaDB and PostgreSQL are popular open-source relational databases used for cloud-based applications. We will be deploying identically sized RDS instances for these two databases on Intel 3^rd generation Xeon Scalable and Graviton based instances and running the commonly used Sysbench workload to compare their relative performance.

Instance Configuration:

The details about the Amazon EC2 instance choices that were made with Intel and Graviton instances are shown in Table 1.

Table 1: Instance configuration details for the testing

Workload Configuration:

Details about the workload and its attributes are shown in Table 2. Sysbench 1.0.18 was run 4 times per configuration and the results were then averaged for both MariaDB and PostgreSQL.

Table 2: Workload configuration details for the testing

MariaDB Results:

The results from the sysbench testing for MariaDB are shown in Table 3. The queries per second (QPS) were calculated and the performance compared between Intel and Graviton based instances. The percentage increase in performance for Intel over Graviton was then calculated as shown.

Table 3: MariaDB QPS comparison between Intel and Graviton Instances.

The results were then compared in graphical format as shown below. Intel instances showed a performance improvement over Graviton between 20-30% for MariaDB.

Figure 1: Graphical comparison of sysbench performance for MariaDB between Intel and Graviton based instances (Higher is better)

PostgreSQL Results:

The results from the sysbench testing for PostgreSQL are shown in Table 4. The queries per second (QPS) were calculated and the performance compared between Intel and Graviton based instances. The percentage increase in performance for Intel over Graviton was then calculated as shown.

Table 4: PostgreSQL QPS comparison between Intel and Graviton Instances.

The results were then compared in graphical format as shown below. Intel instances showed a performance improvement over Graviton between 30-50% for PostgreSQL.

Figure 2: Graphical comparison of sysbench performance for PostgreSQL between Intel and Graviton based instances (Higher is better)

Conclusion:

Customers need to be careful with their choice of instances for their workloads in the cloud. Our results show that not all instances are created equal. Intel 3^rd generation Xeon Scalable processors-based instances outperform Amazon similar Graviton based instances for open-source relational databases by 20-50% as the results have shown. Intel’s active participation in the open-source community and its innovative HW and SW optimizations work to boost performance of Database workloads as we have shown. By choosing Intel instances and right sizing them based on their performance characteristics in Amazon RDS, lower TCO with optimal performance can be attained.

Disclosure text:

Tests were performed in October-November 2022 on AWS in region us-east-1. All configurations used general Purpose SSD gp2 storage. Baseline I/O performance for gp2 storage is 3 IOPS for each GiB, with a minimum of 100 IOPS. This relationship means that larger volumes have better performance. For our experiments we used. 550GiB storage with a baseline performance of 1500 IOPS. We ran the following Database Engines: - MariaDB 10.6.10, - PostgreSQL 14.4-R1. These were run on each of 4 DB server Instances described below. Database server used AWS RDS servers with 4 DB Instance types.

db.r6g – memory-optimized instance classes powered by AWS Graviton2 processors                            

1. db.r6g.8xlarge, 32 vCPU, 256 GB Memory & 12 Gbps Network interface
2. db.r6g.4xlarge, 16 vCPU, 128             GB Memory  & Up to 10 Gbps Network interface                            

db.r6i – memory-optimized instance classes powered by 3rd Generation Intel Xeon Scalable processors

1. db.r6i.8xlarge, 32 vCPU, 256 GB Memory & 12 Gbps Network interface
2. db.r6i.4xlarge, 16 vCPU, 128               GB Memory & Up to 10 Gbps Network interface

Pricing URL for MariaDB: https://aws.amazon.com/rds/mariadb/pricing/                                               

For PostgreSQL:   https://aws.amazon.com/rds/postgresql/pricing/                                           

DB Client machine details:  For Database client machine, we used the EC2 instance type: c6i.4xlarge with 16vCPU (8 core), with 32 GB Memory, 75 GB GP2 Storage volume  with 12.5GB Network bandwidth powered by 3rd Generation Intel Xeon Scalable processors. The client machines use the following Software Image (AMI) with Canonical, Ubuntu, 20.04 LTS, amd64 focal image build on 2022-09-14 & ami-0149b2da6ceec4bb0. All DB Instances, as well as the client Instances were run in US-EAST-1 region. Benchmarking Software: We used sysbench tool to load data and to run oltp_read tests on all these configurations. We used sysbench version

1.0.18 (using system LuaJIT 2.1.0-beta3) for all the DB testing.

Disclaimer text:

Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex. Performance results are based on testing as of dates shown in configurations and may not reflect all publicly available updates. See backup for configuration details. No product or component can be absolutely secure. Your costs and results may vary. Intel technologies may require enabled hardware, software or service activation.

Bibliography

[i] https://www.dbta.com/BigDataQuarterly/Articles/The-Past-Present-and-Future-of-Open-Source-Databases-150954.aspx discusses the present and future of open source databases

[ii] https://www.percona.com/blog/comparing-graviton-arm-performance-to-intel-and-amd-for-mysql-part-3/ compares DB Engines (and clients on the same instances) on M6i.* (Intel) , M6a.* (AMD),  M6g.*(Graviton) EC2 instances.

[iii] https://mariadb.com/database-topics/mariadb-vs-mysql/ provides a good comparison of MySQL and MariaDB.

Appendix A: DB Configuration Tuning:

------------------------------------------------------------------------------------------------------

Tuning for MariaDB:

We followed this article for performance tuning mariadb:

https://mariadb.com/resources/blog/10-database-tuning-tips-for-peak-workloads/

The following parameters were tuned.

1. 1. InnoDB Buffer Pool Size

  Making the InnoDB buffer pool size as large as possible ensures you use memory rather than disks for most read operations (because the buffer pool is where data and indexes are cached).

  LEFT IT UNCHANGED from the RDS default which is {DBInstanceClassMemory*3/4}

  where

    DBInstanceClassMemory is a Formula variable with this description:

    (from https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ParamValuesRef.html

2. 2. InnoDB Log File Size

  The redo logs make sure writes are fast and durable, and  the InnoDB redo space size is important for write-intensive workloads. The logs’ size is determined by innodb_log-file-size. For best results, generally you’ll want to set a combined total size to be at least 1/4 (or even 1/2) of the InnoDB buffer pool size, or equal to one hour’s worth of log entries during peak load. For MariaDB, we set innodb_log_file_size as {DBInstanceClassMemory*(3/4)*(1/4)}:

- We computed and entered the number in a custom parameter group.

innodb_log_file_size

For 4xl instance this is   25769803776 (24GB of log file size for 128GB of RAM in that instance)

For 8xl instance this is   51539607552 (48GB of log file size for 256GB of RAM in that instance)

Tuning for PostgreSQL:

+-----------------------------------------------------------------------------+

CHANGED THIS FOR EVERY DB Instance class before DB Instance creation:

+-----------------------------------------------------------------------------+

max_wal_size = '96GB'

-->Default is 2048 (specified in MB) 

16xl - 393216

8xl - 196608

4xl = 98304

2xl - 49152

+-----------------------------------------------------------------------------+

Refer to the blog:

https://www.percona.com/blog/2021/01/22/postgresql-on-arm-based-aws-ec2-instances-is-it-any-good/