Merge pull request #1244 from jsrz/mysql_tuning_update

Refreshed MySQL Tuning Learning Path

content/learning-paths/servers-and-cloud-computing/mysql_tune/_review.md

@@ -13,25 +13,25 @@
 review:
     - questions:
         question: >
-            When tuning a thread count configuration parameter like innodb_read_io_threads or innodb_write_io_threads. What can often be a good starting value?
+            How do you select the number of huge pages that should be used?
         answers:
-            - "One"
-            - "Total number of CPUs on the system"
-            - "Half the number of CPUs on the system"
+            - "Set to the size of the redo log file"
+            - "Divide the buffer pool size by the huge page size"
+            - "Set to the buffer pool size"
         correct_answer: 2                     
         explanation: >
-            The total number of CPUs is a good starting point because it can ensure you are using all compute resources on the system. 
+            We divide by the bugger pool size because we want as much huge page space as there is buffer pool space. 
 
     - questions:
         question: >
             What is the recommended size for the MySQL buffer pool?
         answers:
-            - "Up to 40% of system memory"
-            - "Up to 20% of system memory"
-            - "Up to 80% of system memory"
+            - "Up to 30-40% of system memory"
+            - "Up to 10-20% of system memory"
+            - "Up to 70-80% of system memory"
         correct_answer: 3
         explanation: >
-            The MySQL documentation suggests up to 80% of system memory. Depending on the use case, it's also possible that a much smaller percentage performs just as well as 80%.
+            The MySQL documentation suggests up to 80% of system memory. Depending on the use case, it's also possible that a much smaller percentage performs just as well as 80%. Buffer pool size is also automatically set to 75% of system memory if you use the innodb_dedicated_server option (See MySQL docs).
                
     - questions:
         question: >

content/learning-paths/servers-and-cloud-computing/mysql_tune/before_and_after.md

@@ -6,8 +6,12 @@ layout: "learningpathall"
 
 ##  About database performance tuning
 
-Deployment configurations and the profile of SQL requests made by clients will differ based on your use case. This means there is no one size fits all set of tuning parameters for `MySQL`.  Use the information in this learning path to help you tune `MySQL` for your use case.
+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`.
 
 ##  Importance of tuning
 
-Application tuning allows you to gain performance without scaling your deployment up (bigger machines) or out (more machines). You have the option to use the gained performance or trade it for cost savings by reducing the total compute resources provisioned. Requirements vary based on the use case. 
+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. 
+
+##  Note on MySQL Documentation
+
+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.

content/learning-paths/servers-and-cloud-computing/mysql_tune/kernel_comp_lib.md

@@ -1,75 +1,52 @@
 ---
 # User change
-title: "System, Kernel, compiler, and Libraries"
+title: "System, Kernel, Compiler, and Libraries"
 
 weight: 3 # 1 is first, 2 is second, etc.
 
 # Do not modify these elements
 layout: "learningpathall"
 ---
 
-##  Storage technology and file system format
+##   Storage technology, file system format, and disk scheduling
 
-The underlying storage technology and the file system format can impact performance significantly. In general, locally attached SSD storage will perform best. However, network based storage systems can perform well. As always, performance is dependent on the request profile coming from clients. You should spend some time studying and experimenting with different storage technologies and configuration options.
+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.
 
-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.
+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).
+
+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.
 
 ##  MySQL storage engines
 
-There are different storage engines available for `MySQL`. The default storage engine is `InnoDB`. `InnoDB` is good for performance testing and tuning.
+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.
 
-Information on alternative storage engines can be found in the [MySQL documentation](https://dev.mysql.com/doc/refman/8.0/en/storage-engines.html).
+Information on alternative storage engines can be found in the [MySQL documentation](https://dev.mysql.com/doc/refman/en/storage-engines.html).
 
 ##  Kernel configuration
 
 `MySQL` can benefit from adjustments to kernel parameters. Below is a list of kernel related settings that can have a positive impact on performance.
 
-### Linux-PAM limits
-
-Linux-PAM limits can be changed in the `/etc/security/limits.conf` file, or by using the `ulimit` command. 
-
-If you want more information about how to display and modify parameters check the documentation of the `ulimit` command. 
-
-To display all limits:
-```bash
-ulimit -a
-```
-
-To display the `memlock` (Max locked-in-memory address space) limit only:
-```bash
-ulimit -l
-```
-
-`memlock` is the only PAM limit which is useful to adjust for `MySQL`. 
-
-The suggested value for `memlock` is `unlimited` when using huge pages with `MySQL`. 
-
-Enabling huge pages can result in significant performance gains (discussed below).
-
-The suggestion to set `memlock` when huge pages are enabled can be found in the [MySQL documentation](https://dev.mysql.com/doc/refman/8.1/en/large-page-support.html).
-
-
 ### Linux virtual memory subsystem
 
-Making changes to the Linux Virtual Memory subsystem can also improve performance. 
+Making changes to the Linux Virtual Memory subsystem can improve performance. 
 
 These settings can be changed in the `/etc/sysctl.conf` file, or by using the `sysctl` command. 
 
-If you want more information about how to display and modify virtual memory parameters check the documentation of the `sysctl` command. 
-
-Documentation on each of these 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).
+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).
 
-To list all kernel parameters available:
+To list all sysctl parameters available:
 
 ```bash
 sudo sysctl -a
 ```
 
+See the `sysctl` command documentation for more.
+
 ### Huge memory pages
 
  `MySQL` benefits from using huge memory pages. Huge pages reduce how often virtual memory pages are mapped to physical memory. 
 
-To see the current memory page configuration, run the following command on the host:
+To see the current huge memory page configuration, run the following command on the host:
 
 ```bash
 cat /proc/meminfo | grep ^Huge
@@ -86,11 +63,11 @@ Hugepagesize:       2048 kB
 Hugetlb:               0 kB
 ```
 
-Huge pages are not being used if `HugePages_Total` is 0 (this is the default). 
+Huge pages are not being used if `HugePages_Total` is 0 (this is typically the default). 
 
-Also note that `Hugepagesize` is 2MB which is the typical default for huge pages on Linux. 
+Also note that `Hugepagesize` is 2MiB which is the typical default for huge pages on Linux. 
 
-The kernel parameter that enables huge pages is shown below:
+The sysctl parameter that enables huge pages is shown below:
 
 ```output
 vm.nr_hugepages
@@ -114,11 +91,9 @@ sudo sh -c 'echo "vm.nr_hugepages=500" >> /etc/sysctl.conf'
 
 ### Selecting the number of huge pages to use
 
-You should set `vm.nr_hugepages` to a value that gives a total huge page space slightly larger than the `MySQL` buffer pool size (discussed later). 
-
-It should be slightly larger than the buffer pool because `MySQL` will use additional memory for things like connection management.
+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.
 
-More information on the different parameters that affect the configuration of huge pages can be found in the [admin-guide for hugetlbpage in the Linux source code](https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/mm/hugetlbpage.rst).
+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