Bookmark this page

Guided Exercise: Adjust Tuning Profiles

In this exercise, you tune server performance by activating the tuned service and applying a tuning profile.

Outcomes

  • Configure a system to use a tuning profile.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

This command prepares your environment and ensures that all required resources are available.

[student@workstation ~]$ lab start tuning-profiles

Instructions

  1. Log in to servera as the student user.

    [student@workstation ~]$ ssh student@servera
    ...output omitted...
    [student@servera ~]$
  2. Verify that the tuned package is installed, enabled, and started.

    1. Verify that the tuned package is installed.

      [student@servera ~]$ dnf list tuned
      ...output omitted...
      Installed Packages
      tuned.noarch              2.18.0-1.el9                 @System
    2. Verify that the service is enabled.

      [student@servera ~]$ systemctl is-enabled tuned
      enabled
    3. Verify that the service is currently running.

      [student@servera ~] systemctl is-active tuned
      active
  3. List the available tuning profiles and identify the active profile.

    [student@servera ~]$ sudo tuned-adm list
    [sudo] password for student: student
    Available profiles:
    - accelerator-performance     - Throughput performance based tuning with disabled higher latency STOP states
    - balanced                    - General non-specialized tuned profile
    - desktop                     - Optimize for the desktop use-case
    - hpc-compute                 - Optimize for HPC compute workloads
    - intel-sst                   - Configure for Intel Speed Select Base Frequency
    - latency-performance         - Optimize for deterministic performance at the cost of increased power consumption
    - network-latency             - Optimize for deterministic performance at the cost of increased power consumption, focused on low latency network performance
    - network-throughput          - Optimize for streaming network throughput, generally only necessary on older CPUs or 40G+ networks
    - optimize-serial-console     - Optimize for serial console use.
    - powersave                   - Optimize for low power consumption
    - throughput-performance      - Broadly applicable tuning that provides excellent performance across a variety of common server workloads
    - virtual-guest               - Optimize for running inside a virtual guest
    - virtual-host                - Optimize for running KVM guests
    Current active profile: virtual-guest
  4. Review the tuned.conf configuration file for the current active profile, virtual-guest. You can find the tuned.conf configuration file in the /usr/lib/tuned/virtual-guest directory. The virtual-guest tuning profile is based on the throughput-performance profile, but it sets different values for the vm.dirty_ratio and vm.swappiness parameters. Verify that the virtual-guest tuning profile applies these values on your system.

    1. Review the virtual-guest configuration file in the /usr/lib/tuned/virtual-guest directory. Verify the values for the vm.dirty_ratio and vm.swappiness parameters.

      [student@servera ~]$ cat /usr/lib/tuned/virtual-guest/tuned.conf
      #
      # tuned configuration
      #
      
      [main]
      summary=Optimize for running inside a virtual guest
      include=throughput-performance
      
      [sysctl]
      # If a workload mostly uses anonymous memory and it hits this limit, the entire
      # working set is buffered for I/O, and any more write buffering would require
      # swapping, so it's time to throttle writes until I/O can catch up.  Workloads
      # that mostly use file mappings may be able to use even higher values.
      #
      # The generator of dirty data starts writeback at this percentage (system default
      # is 20%)
      vm.dirty_ratio = 30
      
      # Filesystem I/O is usually much more efficient than swapping, so try to keep
      # swapping low.  It's usually safe to go even lower than this on systems with
      # server-grade storage.
      vm.swappiness = 30
    2. Verify that the tuning profile applies these values on your system.

      [student@servera ~]$ sysctl vm.dirty_ratio
      vm.dirty_ratio = 30
      [student@servera ~]$ sysctl vm.swappiness
      vm.swappiness = 30
  5. Review the tuned.conf configuration file for the virtual-guest parent's tuning profile, throughput-performance. You can find it in the /usr/lib/tuned/throughput-performance directory. Notice that the throughput-performance tuning profile sets a different value for the vm.dirty_ratio and vm.swappiness parameters, although the virtual-guest profile overwrites them. Verify that the virtual-guest tuning profile applies the value for the vm.dirty_background_ratio parameter, which it inherits from the throughput-performance profile.

    1. Review the throughput-performance configuration file in the /usr/lib/tuned/throughput-performance directory. Verify the values for the vm.dirty_ratio, vm.swappiness, and vm.dirty_background_ratio parameters.

      [student@servera ~]$ cat /usr/lib/tuned/throughput-performance/tuned.conf
      #
      # tuned configuration
      #
      
      [main]
      summary=Broadly applicable tuning that provides excellent performance across a variety of common server workloads
      
      ...output omitted...
      
      [sysctl]
      # If a workload mostly uses anonymous memory and it hits this limit, the entire
      # working set is buffered for I/O, and any more write buffering would require
      # swapping, so it's time to throttle writes until I/O can catch up.  Workloads
      # that mostly use file mappings may be able to use even higher values.
      #
      # The generator of dirty data starts writeback at this percentage (system default
      # is 20%)
      vm.dirty_ratio = 40
      
      # Start background writeback (via writeback threads) at this percentage (system
      # default is 10%)
      vm.dirty_background_ratio = 10
      
      # PID allocation wrap value.  When the kernel's next PID value
      # reaches this value, it wraps back to a minimum PID value.
      # PIDs of value pid_max or larger are not allocated.
      #
      # A suggested value for pid_max is 1024 * <# of cpu cores/threads in system>
      # e.g., a box with 32 cpus, the default of 32768 is reasonable, for 64 cpus,
      # 65536, for 4096 cpus, 4194304 (which is the upper limit possible).
      #kernel.pid_max = 65536
      
      # The swappiness parameter controls the tendency of the kernel to move
      # processes out of physical memory and onto the swap disk.
      # 0 tells the kernel to avoid swapping processes out of physical memory
      # for as long as possible
      # 100 tells the kernel to aggressively swap processes out of physical memory
      # and move them to swap cache
      vm.swappiness=10
      
      ...output omitted...
    2. Verify that the virtual-guest tuning profile applies the inherited vm.dirty_background_ratio parameter.

      [student@servera ~]$ sysctl vm.dirty_background_ratio
      vm.dirty_background_ratio = 10
  6. Change the current active tuning profile to throughput-performance, and then confirm the results. Verify that the vm.dirty_ratio and vm.swappiness parameters change to the values in the throughput-performance configuration file.

    1. Change the current active tuning profile.

      [student@servera ~]$ sudo tuned-adm profile throughput-performance
    2. Confirm that throughput-performance is the active tuning profile.

      [student@servera ~]$ sudo tuned-adm active
      Current active profile: throughput-performance
    3. Verify the values for the vm.dirty_ratio and vm.swappiness parameters.

      [student@servera ~]$ sysctl vm.dirty_ratio
      vm.dirty_ratio = 40
      [student@servera ~]$ sysctl vm.swappiness
      vm.swappiness = 10
  7. Return to the workstation machine as the student user.

    [student@servera ~]$ exit
    logout
    Connection to servera closed.
    [student@workstation ~]$

Finish

On the workstation machine, change to the student user home directory and use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish tuning-profiles

This concludes the section.

Revision: rh199-9.0-4fecb06