Merge pull request #3431 from anupras-mohapatra-arm/servers-and-cloud-computing

Tuning MySQL LP editorial review

Author: jasonrandrews

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 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 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.
+  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 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: >-
+      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
 

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. 

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,27 +11,29 @@ 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.
 
 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. 
 
-## MySQL storage engines
+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
+### 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
+#### Linux virtual memory subsystem
 
 Making changes to the Linux virtual memory subsystem can improve performance.
 
@@ -45,17 +47,17 @@ 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.
 
 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.
 
 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.
 
@@ -116,7 +114,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 +126,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 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.