You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/learning-paths/servers-and-cloud-computing/mysql_tune/_index.md
+24-9Lines changed: 24 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,15 +1,19 @@
1
1
---
2
-
title: Learn how to Tune MySQL
2
+
title: Tune MySQL performance on Arm-based platforms
3
+
description: Learn how to tune MySQL configuration, Linux memory settings, and storage options to improve database performance on Arm-based platforms.
3
4
4
5
minutes_to_complete: 30
5
6
6
-
who_is_this_for: This is an advanced topic for software developers and DevOps professionals interested in optimizing MySQL performance on Arm-based VMs in the cloud.
7
+
who_is_this_for: This Learning Path is for database administrators (DBAs) and software developers who want to optimize MySQL performance on Arm-based platforms.
7
8
8
9
learning_objectives:
9
-
- Tune MySQL to increase performance
10
+
- Configure MySQL settings that affect connection handling, memory usage, disk flush behavior, and concurrency.
11
+
- Enable huge pages for MySQL and size them based on the InnoDB buffer pool.
12
+
- Evaluate storage, kernel, compiler, and library choices that can affect MySQL performance.
10
13
11
14
prerequisites:
12
-
- Bare-metal or cloud [installation of MySQL](/learning-paths/servers-and-cloud-computing/mysql/)
15
+
- On-prem or cloud [installation of MySQL](https://dev.mysql.com/doc/refman/en/)
16
+
- A repeatable MySQL workload or benchmark that you can run before and after tuning
description: Learn how to approach MySQL performance tuning as a measurement-driven process and compare baseline results with tuned results.
3
4
weight: 2
4
5
layout: "learningpathall"
5
6
---
6
7
7
-
## About database performance tuning
8
+
## About performance tuning
8
9
9
-
The configuration of a database and the types of requests made by clients to it will differ from use case to use case. This means there is no one size fits all set of tuning parameters for `MySQL`. Use the information in this learning path as general guidance to help with tuning `MySQL`.
10
+
Performance tuning is most useful when you treat it as a measurement process, not a fixed checklist. You can tune by changing one parameter at a time, running a designed experiment, comparing profiles, or using automation and AI-assisted tools to explore a larger configuration space.
10
11
11
-
## Importance of tuning
12
+
There isn't a universal set of tuning parameters that works best for every application. The right settings depend on the workload, data size, memory capacity, storage performance, network behavior, software version, system architecture, operating system, and other application-specific factors.
12
13
13
-
Application tuning allows you to gain performance without scaling a deployment up (bigger machines) or out (more machines). This gives the option to use the gained performance, or to trade it for cost savings by reducing the total compute resources provisioned.
14
+
Whatever method you use, keep the measurements repeatable. Record the system configuration, workload, software versions, and tuning parameters so you can identify which changes improved performance and which changes had little effect.
14
15
15
-
## Note on MySQL Documentation
16
+
## Why tune MySQL
16
17
17
-
All links to [MySQL documentation](https://dev.mysql.com/doc/refman/en/) in this learning path point to the latest version of the documentation. If you are using an older version of MySQL, be sure to change the documentation version after clicking the links.
18
+
MySQL performance can be limited by memory usage, disk I/O, connection handling, concurrency, or synchronization overhead. Tuning helps you use the available compute, memory, and storage resources more efficiently.
19
+
20
+
Improved performance can give you higher throughput, lower latency, or better cost efficiency. A tuned configuration can increase capacity on the same system, or help you meet the same performance target with fewer compute resources.
21
+
22
+
## Example benchmark result
23
+
24
+
The following example shows MySQL throughput with HammerDB TPROC-C before and after tuning on an Arm Neoverse V3 system.
25
+
26
+
![Bar chart comparing MySQL HammerDB TPROC-C normalized NOPM throughput before and after tuning on an Arm Neoverse V3 system. At 128 clients, the out-of-box configuration is 1.00 and the tuned configuration is 15.37.#center](oobvstuned.png"MySQL HammerDB TPROC-C throughput before and after tuning")
27
+
28
+
This benchmark result is an example, not a guaranteed improvement for every workload. Your results depend on the MySQL version, database size, storage device, memory capacity, client thread count, and the queries used in the test.
29
+
30
+
{{% notice Note %}}
31
+
Links to MySQL documentation in this Learning Path point to the latest version of the documentation. If you use an older version of MySQL, select the matching documentation version after opening the links.
title: "Tune system, kernel, compiler, and library settings"
4
+
description: Learn how storage, kernel page size, Linux huge pages, compiler settings, and OpenSSL choices can affect MySQL performance on Arm-based systems.
4
5
5
6
weight: 3# 1 is first, 2 is second, etc.
6
7
7
8
# Do not modify these elements
8
9
layout: "learningpathall"
9
10
---
10
11
11
-
## Storage technology, file system format, and disk scheduling
12
+
## Tune the system around MySQL
12
13
13
-
The underlying storage technology and the file system format can impact performance. In general, locally attached SSD storage will perform best. However, network based storage systems can perform well. You should spend some time studying and experimenting with different storage technologies and configuration options.
14
+
MySQL configuration is only one part of performance tuning. Operating system settings, storage behavior, kernel memory management, compiler choices, and library versions can also affect throughput and latency. This section highlights system-level areas to check before or alongside MySQL-specific tuning.
14
15
15
-
Aside from the storage technology, the file system format used with `MySQL` can impact performance. The `xfs` file system is a good starting point. The `ext4` file system is another good alternative. Last, it is recommended to use storage drives that are dedicated to the database (i.e. not shared with the OS or other applications).
16
+
## Storage technology, file systems, and disk scheduling
16
17
17
-
When running in the cloud, the disk scheduling algorithm is typically set to `noop` or a similar "dumb" algorithm. This is typically optimal for `MySQL` in the cloud, so no adjustment is needed. However, if running `MySQL` on an on-prem server, it's a good idea to double check what the disk scheduling algorithm is, and possibly change it. According to the [Optimizing InnoDB Disk I/O documentation](https://dev.mysql.com/doc/refman/en/optimizing-innodb-diskio.html), `noop` or `deadline` might be better options. It's worth testing this with on-prem systems.
18
+
Storage technology and file system choices can affect performance. In general, locally attached SSD storage performs best, but network-based storage systems can also perform well. Test the storage technologies and configuration options available in your environment.
18
19
19
-
## MySQL storage engines
20
+
The file system used with MySQL can also affect performance. The `xfs` file system is a good starting point, and `ext4` is another good option. For production systems, use storage volumes dedicated to the database instead of sharing them with the operating system or other applications.
20
21
21
-
There are different storage engines available for `MySQL`. The default storage engine is `InnoDB`. `InnoDB` is the default storage engine because it performs the best in the broadest set of use cases.
22
+
When running in the cloud, the disk scheduling algorithm is typically set to `noop` or a similar minimal scheduler. This is usually a good setting for MySQL in cloud environments, so no adjustment is needed. If you run MySQL on an on-premises server, double-check the disk scheduling algorithm and test alternatives. According to the [Optimizing InnoDB Disk I/O documentation](https://dev.mysql.com/doc/refman/en/optimizing-innodb-diskio.html), `noop` or `deadline` might be better options for some systems.
23
+
24
+
## MySQL storage engines
25
+
26
+
MySQL supports different storage engines. The default storage engine is `InnoDB`, which performs best across the broadest set of use cases.
22
27
23
28
Information on alternative storage engines can be found in the [MySQL documentation](https://dev.mysql.com/doc/refman/en/storage-engines.html).
24
29
25
-
## Kernel configuration
30
+
## Kernel configuration
26
31
27
-
`MySQL` can benefit from adjustments to kernel parameters. Below is a list of kernelrelated settings that can have a positive impact on performance.
32
+
MySQL can benefit from adjustments to kernel parameters. The following kernel-related settings can have a positive impact on performance.
28
33
29
34
### Linux virtual memory subsystem
30
35
31
-
Making changes to the Linux Virtual Memory subsystem can improve performance.
36
+
Making changes to the Linux virtual memory subsystem can improve performance.
32
37
33
-
These settings can be changed in the `/etc/sysctl.conf` file, or by using the `sysctl` command.
38
+
You can change these settings by using the `sysctl` command or by adding configuration files under `/etc/sysctl.d/`.
34
39
35
40
Documentation on the virtual memory subsystem parameters can be found in the [admin-guide for sysctl in the Linux source code](https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/sysctl/vm.rst).
36
41
@@ -42,14 +47,35 @@ sudo sysctl -a
42
47
43
48
See the `sysctl` command documentation for more.
44
49
50
+
### Consider 64 KB kernel pages on Arm
51
+
52
+
Some Arm Linux distributions provide kernels built with `64 KB` base pages instead of `4 KB` base pages. This is a kernel selection or build-time choice, not a `sysctl` setting you can change on a running system.
53
+
54
+
A `64 KB` base page can improve some memory-intensive workloads because each base page maps more memory. This can reduce Memory Management Unit (MMU) translation overhead, reduce page-table walk depth, and relieve Translation Lookaside Buffer (TLB) pressure, including instruction-side TLB pressure in the CPU front end.
55
+
56
+
The tradeoff is memory efficiency. Larger base pages can increase internal fragmentation for workloads with many small or sparsely touched mappings, which can reduce the effective amount of memory available to the application and operating system.
57
+
58
+
The benefit is workload dependent, so compare a `4 KB` kernel and a `64 KB` kernel with the same MySQL & storage configuration.
59
+
60
+
Base page size also affects the huge page sizes available on Arm. The common PMD-level huge page sizes are:
For more information, see the Linux kernel documentation for [Memory Layout on AArch64 Linux](https://docs.kernel.org/next/arm64/memory.html) and [HugeTLBpage on ARM64](https://docs.kernel.org/next/arm64/hugetlbpage.html).
68
+
45
69
### Huge memory pages
46
70
47
-
`MySQL` benefits from using huge memory pages. Huge pages reduce how often virtual memory pages are mapped to physical memory.
48
-
71
+
MySQL can benefit from using huge memory pages, especially when the InnoDB buffer pool is large. Huge memory pages have a similar performance goal to `64 KB` base pages: they map more memory per translation entry, which can reduce page-table walks and TLB pressure.
72
+
73
+
The tradeoff is also similar. Huge pages reserve memory in larger chunks, so over-allocating them can reduce the memory available for other uses. Under-allocating them can prevent MySQL from using huge pages at all. The performance impact depends on your workload and system configuration.
74
+
49
75
To see the current huge memory page configuration, run the following command on the host:
50
76
51
77
```bash
52
-
cat /proc/meminfo| grep ^Huge
78
+
grep '^Huge'/proc/meminfo
53
79
```
54
80
55
81
The output should be similar to:
@@ -63,44 +89,51 @@ Hugepagesize: 2048 kB
63
89
Hugetlb: 0 kB
64
90
```
65
91
66
-
Huge pages are not being used if `HugePages_Total` is 0 (this is typically the default).
92
+
Huge pages are not being used if `HugePages_Total` is `0` (this is typically the default).
67
93
68
-
Also note that `Hugepagesize`is 2MiB which is the typical default for huge pages on Linux.
94
+
The `Hugepagesize`value depends on the kernel base page size and platform configuration. Use the value reported by `/proc/meminfo` when calculating `vm.nr_hugepages`.
69
95
70
96
The sysctl parameter that enables huge pages is shown below:
71
97
72
98
```output
73
99
vm.nr_hugepages
74
100
```
75
101
76
-
This parameter sets the number of huge pages you want the kernel to make available to applications.
102
+
This parameter sets the number of huge pages you want the kernel to make available to applications.
77
103
78
-
The total amount of memory that will be used for huge pages will be this number (defaulted to 0) times the `Hugepagesize`.
104
+
The total amount of memory used for huge pages is this number, which defaults to 0, multiplied by the `Hugepagesize` value.
79
105
80
-
As an example, if you want a total of 1GB of huge page space, then you should set `vm.nr_hugepages` to 500 (500x2MB=1GB).
106
+
For example, if you want `1 GiB` of huge page space and `Hugepagesize` is `2 MiB`, set `vm.nr_hugepages` to `512`.
81
107
82
108
```bash
83
-
sudo sysctl -w vm.nr_hugepages=500
109
+
sudo sysctl -w vm.nr_hugepages=512
84
110
```
85
111
86
112
To make the change permanent:
87
113
88
114
```bash
89
-
sudo sh -c 'echo "vm.nr_hugepages=500" >> /etc/sysctl.conf'
115
+
echo"vm.nr_hugepages=512"| sudo tee /etc/sysctl.d/99-mysql-hugepages.conf
116
+
sudo sysctl --system
90
117
```
91
118
92
119
### Selecting the number of huge pages to use
93
120
94
-
You should set `vm.nr_hugepages` to a value that gives a total huge page space equal to or slightly larger than the `MySQL` buffer pool size. Selecting the buffer pool size is discussed in the [Tuning MySQL](/learning-paths/servers-and-cloud-computing/mysql_tune/tuning/) section.
121
+
If huge pages improve your workload, set `vm.nr_hugepages` to a value that gives a total huge page space equal to or slightly larger than the InnoDB buffer pool size, which is controlled by `innodb_buffer_pool_size`.
122
+
123
+
{{% notice Important %}}
124
+
After restarting MySQL with `large-pages=ON`, check both `/proc/meminfo` and the MySQL error log. If the huge page pool is too small, or MySQL cannot allocate huge pages for another reason, InnoDB can fall back to traditional memory and write `Warning: Using conventional memory pool.` to the MySQL error log. You might also see an allocation warning similar to `large_page_aligned_alloc mmap(... bytes) failed; errno 12`.
125
+
{{% /notice %}}
126
+
127
+
Selecting the buffer pool size is discussed in the [Tuning MySQL](/learning-paths/servers-and-cloud-computing/mysql_tune/tuning/) section.
95
128
96
129
Typically, only the number of huge pages needs to be configured. However, for more information on the different parameters that affect the configuration of huge pages, review the [admin-guide for hugetlbpage in the Linux source code](https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/mm/hugetlbpage.rst).
97
130
98
-
## Compiler Considerations
131
+
## Compiler considerations
99
132
100
-
The easiest way to gain performance is to use the latest version of GCC. Aside from that, the flags `-mcpu` and `-flto`can be used to potentially gain additional performance. Usage of these flags is explained in the [Migrating C/C++ applications](/learning-paths/servers-and-cloud-computing/migration/c/) section of the [Migrating applications to Arm servers](/learning-paths/servers-and-cloud-computing/migration/)learning path.
133
+
If you build MySQL from source, the compiler version and optimization flags can affect performance. Use a recent version of GCC, and consider flags such as `-mcpu` and `-flto`for additional optimization. These flags are explained in the [Migrating C/C++ applications](/learning-paths/servers-and-cloud-computing/migration/c/) section of the [Migrating applications to Arm servers](/learning-paths/servers-and-cloud-computing/migration/)Learning Path.
101
134
102
-
## OpenSSL Considerations
135
+
## OpenSSL considerations
103
136
104
-
MySQL relies on [OpenSSL](https://www.openssl.org/) for cryptographic operations. Thus, the version of OpenSSL used with MySQL (and the GCC version and switches used to compile it) can impact performance. Typically using the Linux distribution default version of OpenSSL is sufficient.
137
+
MySQL relies on [OpenSSL](https://www.openssl.org/) for cryptographic operations. The OpenSSL version used with MySQL, and the compiler version and switches used to build it, can affect performance. The default OpenSSL version provided by your Linux distribution is typically sufficient.
105
138
106
-
However, it is possible to use newer versions of OpenSSL which could yield performance improvements. This is achieved by building and installing OpenSSL before building MySQL.
139
+
If you build MySQL from source, you can also build and install a newer version of OpenSSL before building MySQL. This might improve performance for workloads that spend significant time in cryptographic operations.
0 commit comments