second pass

Author: anupras-mohapatra-arm

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. 

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.