From a1393cbcdbb58291527a731796a2fb4a0f182ba4 Mon Sep 17 00:00:00 2001 From: anupras-mohapatra-arm Date: Fri, 26 Jun 2026 16:13:18 -0500 Subject: [PATCH 1/5] first pass edits --- .../mysql_tune/before_and_after.md | 10 +++++-- .../mysql_tune/kernel_comp_lib.md | 28 +++++++++++-------- .../mysql_tune/tuning.md | 22 ++++++++++----- 3 files changed, 40 insertions(+), 20 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/mysql_tune/before_and_after.md b/content/learning-paths/servers-and-cloud-computing/mysql_tune/before_and_after.md index d8e0e829a4..4d1863c904 100644 --- a/content/learning-paths/servers-and-cloud-computing/mysql_tune/before_and_after.md +++ b/content/learning-paths/servers-and-cloud-computing/mysql_tune/before_and_after.md @@ -1,5 +1,5 @@ --- -title: "Measure MySQL tuning impact" +title: Measure the impact of tuning MySQL description: Learn how to approach MySQL performance tuning as a measurement-driven process and compare baseline results with tuned results. weight: 2 layout: "learningpathall" @@ -15,7 +15,7 @@ Whatever method you use, keep the measurements repeatable. Record the system con ## Why tune MySQL -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. +MySQL performance can be limited by memory usage, disk I/O, connection handling, concurrency, or synchronization overhead. By tuning MySQL, you can use the available compute, memory, and storage resources more efficiently. 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. @@ -30,3 +30,9 @@ This benchmark result is an example, not a guaranteed improvement for every work {{% notice Note %}} 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. {{% /notice %}} + +## What you've learned and what's next + +You've now learned why tuning MySQL is beneficial, and reviewed an example benchmark result demonstrating improvement in throughput after tuning. + +Next, you'll learn about different system parameters that you can tune for performance. \ No newline at end of file diff --git a/content/learning-paths/servers-and-cloud-computing/mysql_tune/kernel_comp_lib.md b/content/learning-paths/servers-and-cloud-computing/mysql_tune/kernel_comp_lib.md index 2cacd23636..212d02950c 100644 --- a/content/learning-paths/servers-and-cloud-computing/mysql_tune/kernel_comp_lib.md +++ b/content/learning-paths/servers-and-cloud-computing/mysql_tune/kernel_comp_lib.md @@ -1,6 +1,6 @@ --- # User change -title: "Tune system, kernel, compiler, and library settings" +title: Tune storage, kernel, compiler, and library settings for performance description: Learn how storage, kernel page size, Linux huge pages, compiler settings, and OpenSSL choices can affect MySQL performance on Arm-based systems. weight: 3 # 1 is first, 2 is second, etc. @@ -11,9 +11,9 @@ layout: "learningpathall" ## Tune the system around MySQL -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. +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. The following are system-level areas to check before or alongside MySQL-specific tuning. -## Storage technology, file systems, and disk scheduling +### Storage technology, file systems, and disk scheduling 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. @@ -21,17 +21,17 @@ The file system used with MySQL can also affect performance. The `xfs` file syst 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. -## MySQL storage engines +### MySQL storage engines MySQL supports different storage engines. The default storage engine is `InnoDB`, which performs best across the broadest set of use cases. Information on alternative storage engines can be found in the [MySQL documentation](https://dev.mysql.com/doc/refman/en/storage-engines.html). -## Kernel configuration +### Kernel configuration MySQL can benefit from adjustments to kernel parameters. The following kernel-related settings can have a positive impact on performance. -### Linux virtual memory subsystem +#### Linux virtual memory subsystem Making changes to the Linux virtual memory subsystem can improve performance. @@ -45,9 +45,9 @@ To list all sysctl parameters available: sudo sysctl -a ``` -See the `sysctl` command documentation for more. +For more information, see the `sysctl` command documentation. -### Consider 64 KB kernel pages on Arm +#### Consider 64 KB kernel pages on Arm 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. @@ -116,7 +116,7 @@ echo "vm.nr_hugepages=512" | sudo tee /etc/sysctl.d/99-mysql-hugepages.conf sudo sysctl --system ``` -### Selecting the number of huge pages to use +#### Selecting the number of huge pages to use 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`. @@ -128,12 +128,18 @@ Selecting the buffer pool size is discussed in the [Tuning MySQL](/learning-path 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). -## Compiler considerations +### Compiler considerations 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. -## OpenSSL considerations +### OpenSSL considerations 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. 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. + +## What you've learned and what's next + +You've now explored enhancements you can make at the system-level related to storage, memory pages, compiler flags, and OpenSSL to improve MySQL performance on Arm. + +Next, you'll learn about specific MySQL parameters that you can tune for performance. \ No newline at end of file diff --git a/content/learning-paths/servers-and-cloud-computing/mysql_tune/tuning.md b/content/learning-paths/servers-and-cloud-computing/mysql_tune/tuning.md index c43265f903..90c43f648c 100644 --- a/content/learning-paths/servers-and-cloud-computing/mysql_tune/tuning.md +++ b/content/learning-paths/servers-and-cloud-computing/mysql_tune/tuning.md @@ -1,6 +1,6 @@ --- # User change -title: "Tune MySQL configuration" +title: Tune MySQL configuration for performance description: Learn how to tune MySQL server parameters for connections, memory, disk flushing, transaction durability, I/O capacity, and lock polling. weight: 4 # 1 is first, 2 is second, etc. @@ -9,15 +9,17 @@ weight: 4 # 1 is first, 2 is second, etc. layout: "learningpathall" --- -## MySQL configuration +## Update MySQL parameters You can set MySQL server configuration parameters in an option file or on the `mysqld` command line. -For persistent tuning, use an option file so the configuration can be reviewed, version controlled, and applied consistently when MySQL restarts. For more information, see the MySQL [Specifying Program Options documentation](https://dev.mysql.com/doc/refman/en/program-options.html). +For persistent tuning, use an option file so the configuration can be reviewed, version controlled, and applied consistently when MySQL restarts. For more information, see [Specifying Program Options](https://dev.mysql.com/doc/refman/en/program-options.html) in MySQL documentation. The examples in this section are intended for the `[mysqld]` group in a MySQL option file. +{{% notice Note %}} In general, leave most MySQL settings at their defaults and change them only when you have a workload requirement, test result, profile, or observed bottleneck that supports the change. +{{% /notice %}} ### Connections and prepared statements @@ -35,7 +37,7 @@ The [`max_prepared_stmt_count`](https://dev.mysql.com/doc/refman/en/server-syste ### Dedicated server configuration -If the system only runs MySQL, enable the dedicated server setting: +If the system runs only MySQL, enable the dedicated server setting: ```ini innodb_dedicated_server=ON @@ -91,7 +93,7 @@ innodb_dedicated_server=ON innodb_redo_log_capacity=32G ``` -The [`innodb_redo_log_capacity`](https://dev.mysql.com/doc/refman/en/innodb-parameters.html#sysvar_innodb_redo_log_capacity) parameter controls the amount of disk space used for redo log files. It was introduced in MySQL 8.0.30. In earlier MySQL versions, [`innodb_log_file_size`](https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_log_file_size) and [`innodb_log_files_in_group`](https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_log_files_in_group) control redo log size and behavior. +The [`innodb_redo_log_capacity`](https://dev.mysql.com/doc/refman/en/innodb-parameters.html#sysvar_innodb_redo_log_capacity) parameter controls the amount of disk space used for redo log files. It was introduced in MySQL `8.0.30`. In earlier MySQL versions, [`innodb_log_file_size`](https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_log_file_size) and [`innodb_log_files_in_group`](https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_log_files_in_group) control redo log size and behavior. The auto-sized `innodb_redo_log_capacity` value is a starting point. Increasing it can improve write-heavy workloads by giving InnoDB more redo log space before checkpoints limit write throughput. An explicit `innodb_redo_log_capacity` value overrides the value calculated by `innodb_dedicated_server` for that variable, while still allowing `innodb_dedicated_server` to size other settings such as `innodb_buffer_pool_size`. When you override one of the automatically configured variables, MySQL prints a startup warning such as `Option innodb_dedicated_server is ignored for innodb_redo_log_capacity`. That warning is expected for the overridden variable. @@ -107,12 +109,12 @@ large-pages=ON Turning on [`large-pages`](https://dev.mysql.com/doc/refman/en/server-system-variables.html#sysvar_large_pages) can improve performance when MySQL uses a large InnoDB buffer pool. Larger pages map more memory per translation entry, which can reduce page-table walks and TLB pressure. -Huge pages must also be configured at the Linux kernel level. See the [system, kernel, compiler, and library settings](/learning-paths/servers-and-cloud-computing/mysql_tune/kernel_comp_lib/) section for huge page setup instructions. +Huge pages must also be configured at the Linux kernel level. For huge page setup instructions, see the [system, kernel, compiler, and library settings](/learning-paths/servers-and-cloud-computing/mysql_tune/kernel_comp_lib/) section of this Learning Path. Divide the buffer pool size by the huge page size to estimate the number of huge pages needed. Use the `Hugepagesize` value from `/proc/meminfo`, and allocate enough huge pages for a total huge page space equal to or slightly larger than the buffer pool. {{% notice Important %}} -After restarting MySQL with `large-pages=ON`, check `/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 print `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`. +After restarting MySQL with `large-pages=ON`, check `/proc/meminfo` and the MySQL error log. If the huge page pool is too small, or MySQL can't allocate huge pages for another reason, InnoDB can fall back to traditional memory and print `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`. {{% /notice %}} You don't usually need to change other memory parameters unless you observe a specific issue. One optional area to test is [InnoDB buffer pool prefetching](https://dev.mysql.com/doc/refman/en/innodb-performance-read_ahead.html). Lowering [`innodb_read_ahead_threshold`](https://dev.mysql.com/doc/refman/en/innodb-parameters.html#sysvar_innodb_read_ahead_threshold) from the default can help workloads with predictable sequential access patterns, while [`innodb_random_read_ahead`](https://dev.mysql.com/doc/refman/en/innodb-parameters.html#sysvar_innodb_random_read_ahead) can help some workloads and hurt others. Treat these settings as workload-specific experiments. @@ -168,3 +170,9 @@ innodb_sync_spin_loops=30 The [`innodb_sync_spin_loops`](https://dev.mysql.com/doc/refman/en/innodb-parameters.html#sysvar_innodb_sync_spin_loops) parameter controls how many times a thread checks whether an InnoDB mutex is free before yielding execution to another thread. Profiling MySQL under heavy load on Arm with Linux `perf` can show time spent waiting for locks. Increasing `innodb_sync_spin_loops` can reduce context switching when locks are released quickly, but setting it too high can waste power and delay other useful work. Keep the default value, `30`, unless profiling and measured performance show that a different value helps. For more information, see the MySQL [Configuring Spin Lock Polling documentation](https://dev.mysql.com/doc/refman/en/innodb-performance-spin_lock_polling.html). + +## What you've learned + +You've now explored various MySQL parameters you can tune for improved performance on Arm. + +You can use the guidance in this Learning Path to optimize the performance of your MySQL databases. From b96db6755efd9378ca1b0309c3bea388cdf55e05 Mon Sep 17 00:00:00 2001 From: anupras-mohapatra-arm Date: Fri, 26 Jun 2026 16:28:13 -0500 Subject: [PATCH 2/5] second pass --- .../mysql_tune/kernel_comp_lib.md | 18 ++++++------ .../mysql_tune/tuning.md | 28 +++++++++++++------ 2 files changed, 28 insertions(+), 18 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/mysql_tune/kernel_comp_lib.md b/content/learning-paths/servers-and-cloud-computing/mysql_tune/kernel_comp_lib.md index 212d02950c..5a140cf703 100644 --- a/content/learning-paths/servers-and-cloud-computing/mysql_tune/kernel_comp_lib.md +++ b/content/learning-paths/servers-and-cloud-computing/mysql_tune/kernel_comp_lib.md @@ -19,17 +19,19 @@ Storage technology and file system choices can affect performance. In general, l 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. -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. +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. ### MySQL storage engines MySQL supports different storage engines. The default storage engine is `InnoDB`, which performs best across the broadest set of use cases. -Information on alternative storage engines can be found in the [MySQL documentation](https://dev.mysql.com/doc/refman/en/storage-engines.html). +For more information on alternative storage engines, see the [MySQL storage engine documentation](https://dev.mysql.com/doc/refman/en/storage-engines.html). ### Kernel configuration -MySQL can benefit from adjustments to kernel parameters. The following kernel-related settings can have a positive impact on performance. +MySQL can benefit from adjustments to kernel parameters. The following kernel-related settings can improve performance. #### Linux virtual memory subsystem @@ -55,7 +57,7 @@ A `64 KB` base page can improve some memory-intensive workloads because each bas 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. -The benefit is workload dependent, so compare a `4 KB` kernel and a `64 KB` kernel with the same MySQL & storage configuration. +The benefit is workload dependent, so compare a `4 KB` kernel and a `64 KB` kernel with the same MySQL and storage configuration. Base page size also affects the huge page sizes available on Arm. The common PMD-level huge page sizes are: @@ -93,11 +95,7 @@ Huge pages are not being used if `HugePages_Total` is `0` (this is typically the 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`. -The sysctl parameter that enables huge pages is shown below: - -```output -vm.nr_hugepages -``` +The sysctl parameter that enables huge pages is `vm.nr_hugepages`. This parameter sets the number of huge pages you want the kernel to make available to applications. @@ -140,6 +138,6 @@ If you build MySQL from source, you can also build and install a newer version o ## What you've learned and what's next -You've now explored enhancements you can make at the system-level related to storage, memory pages, compiler flags, and OpenSSL to improve MySQL performance on Arm. +You've now explored changes you can make at the system-level related to storage, memory pages, compiler flags, and OpenSSL to improve MySQL performance on Arm. Next, you'll learn about specific MySQL parameters that you can tune for performance. \ No newline at end of file diff --git a/content/learning-paths/servers-and-cloud-computing/mysql_tune/tuning.md b/content/learning-paths/servers-and-cloud-computing/mysql_tune/tuning.md index 90c43f648c..53b5517aaf 100644 --- a/content/learning-paths/servers-and-cloud-computing/mysql_tune/tuning.md +++ b/content/learning-paths/servers-and-cloud-computing/mysql_tune/tuning.md @@ -9,11 +9,11 @@ weight: 4 # 1 is first, 2 is second, etc. layout: "learningpathall" --- -## Update MySQL parameters +## Choose MySQL parameters for tuning You can set MySQL server configuration parameters in an option file or on the `mysqld` command line. -For persistent tuning, use an option file so the configuration can be reviewed, version controlled, and applied consistently when MySQL restarts. For more information, see [Specifying Program Options](https://dev.mysql.com/doc/refman/en/program-options.html) in MySQL documentation. +For persistent tuning, use an option file so the configuration can be reviewed, version controlled, and applied consistently when MySQL restarts. For more information, see the MySQL[Specifying Program Options](https://dev.mysql.com/doc/refman/en/program-options.html) documentation. The examples in this section are intended for the `[mysqld]` group in a MySQL option file. @@ -95,7 +95,11 @@ innodb_redo_log_capacity=32G The [`innodb_redo_log_capacity`](https://dev.mysql.com/doc/refman/en/innodb-parameters.html#sysvar_innodb_redo_log_capacity) parameter controls the amount of disk space used for redo log files. It was introduced in MySQL `8.0.30`. In earlier MySQL versions, [`innodb_log_file_size`](https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_log_file_size) and [`innodb_log_files_in_group`](https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_log_files_in_group) control redo log size and behavior. -The auto-sized `innodb_redo_log_capacity` value is a starting point. Increasing it can improve write-heavy workloads by giving InnoDB more redo log space before checkpoints limit write throughput. An explicit `innodb_redo_log_capacity` value overrides the value calculated by `innodb_dedicated_server` for that variable, while still allowing `innodb_dedicated_server` to size other settings such as `innodb_buffer_pool_size`. When you override one of the automatically configured variables, MySQL prints a startup warning such as `Option innodb_dedicated_server is ignored for innodb_redo_log_capacity`. That warning is expected for the overridden variable. +The auto-sized `innodb_redo_log_capacity` value is a starting point. Increasing it can improve write-heavy workloads by giving InnoDB more redo log space before checkpoints limit write throughput. An explicit `innodb_redo_log_capacity` value overrides the value calculated by `innodb_dedicated_server` for that variable, while still allowing `innodb_dedicated_server` to size other settings such as `innodb_buffer_pool_size`. + +{{% notice Note %}} +When you override one of the automatically configured variables, MySQL prints a startup warning such as `Option innodb_dedicated_server is ignored for innodb_redo_log_capacity`. That warning is expected for the overridden variable. +{{% /notice %}} Larger redo logs use more disk space and can increase crash recovery time, so test values against both performance and operational requirements. @@ -114,7 +118,9 @@ Huge pages must also be configured at the Linux kernel level. For huge page setu Divide the buffer pool size by the huge page size to estimate the number of huge pages needed. Use the `Hugepagesize` value from `/proc/meminfo`, and allocate enough huge pages for a total huge page space equal to or slightly larger than the buffer pool. {{% notice Important %}} -After restarting MySQL with `large-pages=ON`, check `/proc/meminfo` and the MySQL error log. If the huge page pool is too small, or MySQL can't allocate huge pages for another reason, InnoDB can fall back to traditional memory and print `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`. +After restarting MySQL with `large-pages=ON`, check `/proc/meminfo` and the MySQL error log. If the huge page pool is too small, or MySQL can't allocate huge pages for another reason, InnoDB can fall back to traditional memory and print `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`. {{% /notice %}} You don't usually need to change other memory parameters unless you observe a specific issue. One optional area to test is [InnoDB buffer pool prefetching](https://dev.mysql.com/doc/refman/en/innodb-performance-read_ahead.html). Lowering [`innodb_read_ahead_threshold`](https://dev.mysql.com/doc/refman/en/innodb-parameters.html#sysvar_innodb_read_ahead_threshold) from the default can help workloads with predictable sequential access patterns, while [`innodb_random_read_ahead`](https://dev.mysql.com/doc/refman/en/innodb-parameters.html#sysvar_innodb_random_read_ahead) can help some workloads and hurt others. Treat these settings as workload-specific experiments. @@ -138,12 +144,18 @@ sync_binlog=1 innodb_flush_log_at_trx_commit=1 ``` -The [`sync_binlog`](https://dev.mysql.com/doc/refman/en/replication-options-binary-log.html#sysvar_sync_binlog) parameter controls how often MySQL synchronizes the binary log to disk. The [`innodb_flush_log_at_trx_commit`](https://dev.mysql.com/doc/refman/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit) parameter controls how InnoDB writes and flushes redo log records at transaction commit. +The [`sync_binlog`](https://dev.mysql.com/doc/refman/en/replication-options-binary-log.html#sysvar_sync_binlog) parameter controls how often MySQL synchronizes the binary log to disk. + +The [`innodb_flush_log_at_trx_commit`](https://dev.mysql.com/doc/refman/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit) parameter controls how InnoDB writes and flushes redo log records at transaction commit. When both settings are `1`, MySQL prioritizes transaction durability over peak write throughput. Relaxing either setting can reduce how often transactions wait for binary log and redo log data to be flushed to durable storage. This can improve parallel transaction execution and write throughput, especially on write-heavy workloads, but it increases the time window where committed transactions exist only in memory or operating system cache. {{% notice Warning %}} -Changing `sync_binlog` or `innodb_flush_log_at_trx_commit` away from `1` trades away transaction durability, which is part of ACID compliance. Values such as `sync_binlog=0`, `sync_binlog=N` where `N` is greater than `1`, or `innodb_flush_log_at_trx_commit=0` or `2` can lose committed transactions during a power failure, operating system crash, or unexpected MySQL exit. Change these settings only when your application and recovery process can tolerate potential transaction loss. +Changing `sync_binlog` or `innodb_flush_log_at_trx_commit` away from `1` trades away transaction durability, which is part of ACID compliance. + +Values such as `sync_binlog=0`, `sync_binlog=N` where `N` is greater than `1`, or `innodb_flush_log_at_trx_commit=0` or `2` can lose committed transactions during a power failure, operating system crash, or unexpected MySQL exit. + +Change these settings only when your application and recovery process can tolerate potential transaction loss. {{% /notice %}} ### I/O capacity configuration @@ -173,6 +185,6 @@ Profiling MySQL under heavy load on Arm with Linux `perf` can show time spent wa ## What you've learned -You've now explored various MySQL parameters you can tune for improved performance on Arm. +You've now explored various MySQL parameters you can tune for improved performance. -You can use the guidance in this Learning Path to optimize the performance of your MySQL databases. +You can use the guidance in this Learning Path to optimize the performance of your MySQL databases on Arm. From 8315c95c8d6a6fe31a7667100ca7ec299a6391b2 Mon Sep 17 00:00:00 2001 From: anupras-mohapatra-arm Date: Fri, 26 Jun 2026 16:44:38 -0500 Subject: [PATCH 3/5] adding summary and faqs --- .../mysql_tune/_index.md | 50 ++++++++++++++++++- 1 file changed, 49 insertions(+), 1 deletion(-) diff --git a/content/learning-paths/servers-and-cloud-computing/mysql_tune/_index.md b/content/learning-paths/servers-and-cloud-computing/mysql_tune/_index.md index 9dfcfc421b..458dd836a2 100644 --- a/content/learning-paths/servers-and-cloud-computing/mysql_tune/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/mysql_tune/_index.md @@ -15,9 +15,57 @@ prerequisites: - On-prem or cloud [installation of MySQL](https://dev.mysql.com/doc/refman/en/) - A repeatable MySQL workload or benchmark that you can run before and after tuning +# START generated_summary_faq +generated_summary_faq: + template_version: summary-faq-v3 + generated_at: '2026-06-26T21:28:59Z' + generator: ai + ai_assisted: true + ai_review_required: true + model: gpt-5 + prompt_template: summary-faq-v3 + source_hash: 19acf30951401ec15201ee8e387eb59f9248f627664bc693cf05928233bf2b6f + summary_generated_at: '2026-06-26T21:28:59Z' + summary_source_hash: 19acf30951401ec15201ee8e387eb59f9248f627664bc693cf05928233bf2b6f + faq_generated_at: '2026-06-26T21:28:59Z' + faq_source_hash: 19acf30951401ec15201ee8e387eb59f9248f627664bc693cf05928233bf2b6f + summary: >- + You'll learn how to use a measurement-driven approach to tune MySQL on Arm-based platforms. + You'll explore system factors — storage technology and file systems, + disk scheduling, kernel memory management, compiler, and library versions — that you can adjust. In addition, you'll focus on MySQL parameters related to connection + handling, memory usage, disk flush behavior, and concurrency, and learn how to enable and + size huge pages based on the InnoDB buffer pool. By the end, you'll know what parameters to update for running controlled experiments, + and be able to make persistent configuration choices aligned with your workload. + faqs: + - question: How do I know a MySQL tuning change actually helped? + answer: >- + Run the same repeatable workload before and after the change and compare throughput, latency, + and profiles. Change one parameter at a time or use a designed experiment so results are + attributable to specific settings. + - question: Should I set MySQL parameters in an option file or on the mysqld command line? + answer: >- + Use an option file for persistent tuning so changes are reviewable, version controlled, + and applied on restart. The examples target the [mysqld] group; command-line flags are suitable + for temporary tests. + - question: Which storage option should I use when testing performance? + answer: >- + In general, locally attached SSD storage performs best, but network-based storage can also + perform well. Test the storage technologies and file systems you have, and review disk scheduling + behavior with your workload. + - question: When should I look at kernel, compiler, or library choices instead of MySQL settings? + answer: >- + Evaluate them before or alongside MySQL tuning because operating system settings, kernel + memory management, compiler choices, and library versions can affect throughput and latency. + Treat them as part of the same performance experiment set. + - question: How should I size huge pages for MySQL? + answer: >- + Enable huge pages for MySQL and size them based on the InnoDB buffer pool. This aligns page + allocation with the primary memory consumer in typical MySQL deployments. +# END generated_summary_faq + author: Julio Suarez -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false From b8e8e858d5bd92c2d4f7abc2e312b692ed234ff0 Mon Sep 17 00:00:00 2001 From: anupras-mohapatra-arm Date: Fri, 26 Jun 2026 16:46:49 -0500 Subject: [PATCH 4/5] edits --- .../servers-and-cloud-computing/mysql_tune/_index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/mysql_tune/_index.md b/content/learning-paths/servers-and-cloud-computing/mysql_tune/_index.md index 458dd836a2..5435e9f182 100644 --- a/content/learning-paths/servers-and-cloud-computing/mysql_tune/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/mysql_tune/_index.md @@ -30,9 +30,9 @@ generated_summary_faq: faq_generated_at: '2026-06-26T21:28:59Z' faq_source_hash: 19acf30951401ec15201ee8e387eb59f9248f627664bc693cf05928233bf2b6f summary: >- - You'll learn how to use a measurement-driven approach to tune MySQL on Arm-based platforms. + You'll learn how to use a measurement-driven approach to tune MySQL performance on Arm-based platforms. You'll explore system factors — storage technology and file systems, - disk scheduling, kernel memory management, compiler, and library versions — that you can adjust. In addition, you'll focus on MySQL parameters related to connection + disk scheduling, kernel memory management, compiler, and library versions — that you can adjust. In addition, you'll learn about optimizable MySQL parameters related to connection handling, memory usage, disk flush behavior, and concurrency, and learn how to enable and size huge pages based on the InnoDB buffer pool. By the end, you'll know what parameters to update for running controlled experiments, and be able to make persistent configuration choices aligned with your workload. @@ -45,7 +45,7 @@ generated_summary_faq: - question: Should I set MySQL parameters in an option file or on the mysqld command line? answer: >- Use an option file for persistent tuning so changes are reviewable, version controlled, - and applied on restart. The examples target the [mysqld] group; command-line flags are suitable + and applied on restart. The examples in the Learning Path target the [mysqld] group. Command-line flags are suitable for temporary tests. - question: Which storage option should I use when testing performance? answer: >- From 874785d38a6450d4016e122bac15c643624695e0 Mon Sep 17 00:00:00 2001 From: anupras-mohapatra-arm Date: Fri, 26 Jun 2026 16:55:15 -0500 Subject: [PATCH 5/5] nit --- .../servers-and-cloud-computing/mysql_tune/_index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/learning-paths/servers-and-cloud-computing/mysql_tune/_index.md b/content/learning-paths/servers-and-cloud-computing/mysql_tune/_index.md index 5435e9f182..6baf52b3ab 100644 --- a/content/learning-paths/servers-and-cloud-computing/mysql_tune/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/mysql_tune/_index.md @@ -42,10 +42,10 @@ generated_summary_faq: Run the same repeatable workload before and after the change and compare throughput, latency, and profiles. Change one parameter at a time or use a designed experiment so results are attributable to specific settings. - - question: Should I set MySQL parameters in an option file or on the mysqld command line? + - question: Should I set MySQL parameters in an option file or on the `mysqld` command line? answer: >- Use an option file for persistent tuning so changes are reviewable, version controlled, - and applied on restart. The examples in the Learning Path target the [mysqld] group. Command-line flags are suitable + and applied on restart. The examples in the Learning Path target the `[mysqld]` group. Command-line flags are suitable for temporary tests. - question: Which storage option should I use when testing performance? answer: >-