Cloud
Examine critical components of Cloud computing with Intel® software experts
119 Discussions

Comparing Amazon RDS performance between Intel & Graviton instances for MariaDB and PostgreSQL

Mohan_Potheri
Employee
1 0 12.5K

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 3rd 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 3rd 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 3rd 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 3rd 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.

Category

Attribute

Config1

Config2

Run Info

 

 

 

 

Testing Date

Nov 3-11, 2022

Nov 3-11, 2022

 

Cloud

 AWS

 AWS

Instance Type and CPU

Instance Type

 db.r6g.4xlarge or

 db.r6i.4xlarge

 db.r6g.8xlarge or db.r6i.8xlarge

 

CPU(s)

 16

 32

 

Memory

128GB

256GB

 

Network BW / Instance

12.5 Gbps 

 25 Gbps

 

Storage: Direct attached

SSD GP2  

SSD GP2  

 

Drive Summary

 1 volume 75GB

 1 volume 75GB

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.

 

Category

Attribute

Config1

Config2

Run Info

 

   

 

Benchmark

sysbench 1.0.18

sysbench 1.0.18

 

Dates

Nov 3-11, 2022

Nov 3-11, 2022

CPUs

 

 

 

 

Thread(s) per Core

1,2,4

0.5,1,2

 

Core(s)

16

32

 

CPU Models

Intel 3rd generation Xeon Scalable AWS SKU (r6i), AWS EC2 Graviton2 (r6g)

Intel 3rd generation Xeon Scalable AWS SKU (r6i), AWS EC2 Graviton2 (r6g)

BIOS

 

 

 

 Workload Specific Details

Workload

MariaDB 10.6.10

PostgreSQL 14.4-R1

Command Line

 

sysbench oltp_read_only --time=300 --threads=16 --table-size=100000 --mysql-user=sbtest --mysql-password=password --mysql-host=mariadb-r6g-4xl-v1.couqinukves2.us-east-1.rds.amazonaws.com  --db-driver=mysql --mysql-db=sbtest run

sysbench oltp_read_only --time=300 --threads=16 --table-size=100000 --pgsql-user=sbtest --pgsql-password=password --pgsql-host=pg-r6i-16xl-v1.couqinukves2.us-east-1.rds.amazonaws.com --pgsql-port=5432 --db-driver=pgsql --pgsql-db=sbtest run

 

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.

Queries per second

 

Threads

r6g.4xlarge (Graviton)

r6i.4xlarge (Intel)

Abs Diff

Percentage

Difference (qps)

16

45420.95

55450.305

10029.355

22%

32

82310.385

103531.905

21221.52

26%

64

138068.393

161312.673

23244.28

17%

Threads

r6g.8xlarge (Graviton)

r6i.8xlarge (Intel)

Abs Diff

Percentage

Difference (qps)

16

102649.813

127593.153

24943.34

24%

32

169209.105

216709.785

47500.68

28%

64

250122.328

302356.915

52234.5875

21%

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.

 

Mohan_Potheri_0-1680204009534.png

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.

 

Queries per second

 

Threads

r6g.4xlarge (Graviton)

r6i.4xlarge (Intel)

Abs Diff

Percentage

Difference (qps)

16

58117.2825

65466.75

7349.4675

13%

32

99423.5025

114673.365

15249.8625

15%

64

140116.51

152913.408

12796.8975

9%

Queries per second - 32 vCPU (8xlarge)

 

Threads

r6g.8xlarge (Graviton)

r6i.8xlarge

(Intel)

Abs Diff

Percentage

Difference (qps)

16

81133.195

125247.73

44114.535

54%

32

141914.253

208751.038

66836.785

47%

64

219109.908

288519.455

69409.5475

32%

 

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.

 

Mohan_Potheri_1-1680204009540.png

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 3rd 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

 

  1. 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/

About the Author
Mohan Potheri is a Cloud Solutions Architect with more than 20 years in IT infrastructure, with in depth experience on Cloud architecture. He currently focuses on educating customers and partners on Intel capabilities and optimizations available on Amazon AWS. He is actively engaged with the Intel and AWS Partner communities to develop compelling solutions with Intel and AWS. He is a VMware vExpert (VCDX#98) with extensive knowledge on premises and hybrid cloud. He also has extensive experience with business critical applications such as SAP, Oracle, SQL and Java across UNIX, Linux and Windows environments. Mohan Potheri is an expert on AI/ML, HPC and has been a speaker in multiple conferences such as VMWorld, GTC, ISC and other Partner events.