ExamFinch.com My Study

Study guide

9.3 Manage Tuning Profiles

Practice this exam

Red Hat Certified System Administrator RHCSA

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Lab Setup & Performance-Based Study Strategy

2 Essential Tools: Shell, Redirection & Text Analysis

2.1 Shell Prompt and Command Syntax 2.2 Input-Output Redirection and Pipes 2.3 grep and Regular Expressions for Text Analysis

3 Essential Tools: Remote Access, Users & Text Editing

3.1 Access Remote Systems Using SSH 3.2 Log In and Switch Users in Multiuser Targets 3.3 Create and Edit Text Files

4 Essential Tools: Files, Links & Archives

4.1 Create, Delete, Copy, and Move Files and Directories 4.2 Hard and Soft Links 4.3 Archive and Compress with tar, gzip, and bzip2

5 Essential Tools: Permissions & System Documentation

5.1 List, Set, and Change Standard ugo/rwx Permissions 5.2 System Documentation: man, info, and /usr/share/doc

6 Manage Software: RPM and Flatpak

6.1 Configure Access to RPM Repositories 6.2 Install and Remove RPM Software Packages 6.3 Configure Access to Flatpak Repositories 6.4 Install and Remove Flatpak Software Packages

7 Create Simple Shell Scripts

7.1 Conditional Execution: if, test, and [] 7.2 Looping Constructs for Files and Input 7.3 Process Script Inputs ($1, $2, and Beyond) 7.4 Process Shell Command Output in Scripts

8 Operate Running Systems: Boot and Recovery

8.1 Boot, Reboot, and Shut Down a System Normally 8.2 Boot Systems into Different Targets Manually 8.3 Interrupt the Boot Process to Gain Access

9 Operate Running Systems: Processes and Tuning

9.1 Identify and Kill CPU/Memory Intensive Processes 9.2 Adjust Process Scheduling 9.3 Manage Tuning Profiles

10 Operate Running Systems: Logs, Services & File Transfer

10.1 Locate and Interpret System Log Files and Journals 10.2 Preserve System Journals 10.3 Start, Stop, and Check Status of Network Services 10.4 Securely Transfer Files Between Systems

11 Configure Local Storage: Partitions and LVM

11.1 List, Create, and Delete Partitions on GPT Disks 11.2 Create and Remove Physical Volumes 11.3 Assign Physical Volumes to Volume Groups 11.4 Create and Delete Logical Volumes

12 Configure Local Storage: Mounting and Expansion

12.1 Mount File Systems at Boot by UUID or Label 12.2 Add Partitions, Logical Volumes, and Swap Non-Destructively

13 Create and Configure File Systems: Local FS and Permissions

13.1 Create, Mount, and Use VFAT, ext4, and XFS File Systems 13.2 Extend Existing Logical Volumes 13.3 Diagnose and Correct File Permission Problems

14 Create and Configure File Systems: NFS and autofs

14.1 Mount and Unmount Network File Systems Using NFS 14.2 Configure autofs

15 Deploy and Maintain: Scheduling, Services & Targets

15.1 Schedule Tasks with at, cron, and systemd Timers 15.2 Start, Stop, and Enable Services at Boot 15.3 Configure Systems to Boot into a Specific Target

16 Deploy and Maintain: Time, Software Updates & Bootloader

16.1 Configure Time Service Clients 16.2 Install and Update Software from CDN, Remote Repos, and Local Files 16.3 Modify the System Bootloader

17 Manage Basic Networking

17.1 Configure IPv4 and IPv6 Addresses 17.2 Configure Hostname Resolution 17.3 Configure Network Services to Start Automatically at Boot 17.4 Restrict Network Access Using firewalld and firewall-cmd

18 Manage Users and Groups

18.1 Create, Delete, and Modify Local User Accounts 18.2 Change Passwords and Adjust Password Aging 18.3 Create, Delete, and Modify Local Groups and Memberships 18.4 Configure Privileged Access

19 Manage Security: Firewall, umask & SSH Keys

19.1 Configure Firewall Settings with firewall-cmd and firewalld 19.2 Manage Default File Permissions 19.3 Configure Key-Based Authentication for SSH

20 Manage Security: SELinux Modes and Contexts

20.1 Set Enforcing and Permissive Modes for SELinux 20.2 List and Identify SELinux File and Process Contexts 20.3 Restore Default File Contexts

21 Manage Security: SELinux Ports and Booleans

21.1 Manage SELinux Port Labels 21.2 Use Boolean Settings to Modify SELinux Settings

9.3 Manage Tuning Profiles

Key Takeaways Explain This Topic AI

The tuned service applies system tuning profiles on RHEL; manage them with tuned-adm (list, active, profile, off, recommend).

tuned-adm list shows available profiles; tuned-adm active shows the current profile; tuned-adm profile NAME switches and applies settings.

Common profiles include throughput-performance, latency-performance, balanced, virtual-guest, and desktop—choose what the task names, not personal preference.

Profile selection is persistent while tuned remains enabled/active as configured; verify with tuned-adm active after change and after reboot in practice labs.

Tuning profiles adjust sysctl, disk, and CPU governor-related settings system-wide—they do not replace per-process nice/renice for a single PID.

Last updated: August 2026

9.3 Manage Tuning Profiles

Quick Answer: Use tuned-adm to manage Tuned profiles on RHEL 10. tuned-adm list shows profiles, tuned-adm active shows the current one, and tuned-adm profile <name> applies a profile. Confirm with tuned-adm active . This is system-wide performance/latency tuning—not the same as renice on one process.

Official skill and exam intent

Under Operate running systems , EX200 expects you to manage tuning profiles . On Red Hat Enterprise Linux, that means the Tuned daemon and the tuned-adm CLI: list profiles, see which is active, switch profiles, and leave the system in the requested state after reboot (with Tuned still applying that profile).

Example task language:

  • “Configure the system to use the throughput-performance tuning profile.”
  • “Show the active tuned profile and set it to virtual-guest .”
  • “Ensure the recommended profile is applied.”

Graders check active profile (and that Tuned is working), not whether you recompiled a kernel.

What Tuned does

Tuned is a profile-based system tuning service. A profile is a named collection of settings that may adjust:

  • Kernel sysctl parameters
  • Disk I/O scheduler hints
  • CPU frequency/power related settings
  • Other plug-in managed resources (network, audio, etc. depending on profile)

Profiles live as directories under /usr/lib/tuned/ (shipped) and optionally /etc/tuned/ (local customizations). You rarely hand-edit them on EX200—you select a provided profile with tuned-adm .

  • Piece Role
  • tuned systemd service Daemon that applies and maintains profiles
  • tuned-adm Admin CLI for list/active/profile/recommend/off
  • Profile name e.g. balanced , throughput-performance
  • Service readiness
  • If tuned-adm errors because the daemon is down: systemctl status tuned
  • sudo systemctl enable --now tuned
  • # or
  • sudo systemctl start tuned

On a normal RHEL server image, tuned is often installed and enabled. If a minimal lab removed it, install the package (package name typically tuned ) with DNF when the task implies Tuned must work—only if repositories allow and the task is about profiles. rpm -q tuned

  • systemctl is-enabled tuned
  • systemctl is-active tuned

Exam persistence: For a profile to still apply after reboot, the tuned service should be enabled and the selected profile stored as active. tuned-adm profile NAME both switches the profile and records it for Tuned to re-apply.

  • Core tuned-adm commands
  • List profiles tuned-adm list

Output includes available profile names and usually marks the active profile. Read the list carefully—spelling must match exactly when you switch.

  • Show active profile tuned-adm active
  • Example: Current active profile: balanced

This is your primary verification command after any change.

  • Apply a profile sudo tuned-adm profile throughput-performance
  • sudo tuned-adm profile latency-performance
  • sudo tuned-adm profile virtual-guest
  • sudo tuned-adm profile balanced
  • sudo tuned-adm profile desktop
  • Then immediately: tuned-adm active
  • Recommended profile tuned-adm recommend

# Apply whatever Tuned recommends for this system:

  • sudo tuned-adm profile $(tuned-adm recommend)
  • # Or on some versions there is a direct path—prefer explicit profile name if the task names one

If the task says “use the recommended profile,” run tuned-adm recommend , then tuned-adm profile with that exact string, then tuned-adm active .

  • Turn tuning off sudo tuned-adm off
  • tuned-adm active

off disables profile application (active may report that no profile is active / tuning is off—read the message). Only use when the task asks to disable Tuned profiling—not as a casual “reset.”

Verify operation (optional detail) tuned-adm verify

Reports whether the system settings still match the active profile (useful if something manually changed sysctls afterward). Not always required for credit, but good diagnostics.

Common profile names (recognition set)

Exact sets depend on installed tuned profile packages. Know these names by sight:

  • Profile Typical intent
  • balanced Default-like compromise
  • throughput-performance Favor overall throughput (common server choice)
  • latency-performance Favor low latency
  • network-latency / network-throughput Network-oriented variants when present
  • virtual-guest Guest VM optimizations
  • virtual-host Hypervisor host optimizations
  • desktop Desktop responsiveness/power blend
  • powersave Power saving when present

Exam rule: Use the exact profile string from the task or from tuned-adm list . Do not “upgrade” the request to a profile you like better.

Profiles vs nice vs kill

  • Mechanism Scope Tool
  • Kill process One PID/tree kill / pkill
  • Nice/renice One process’s CPU bias nice / renice
  • Tuned profile Whole system tuning knobs tuned-adm profile

A throughput profile does not stop a runaway binary. Renicing make does not replace a required latency-performance profile. Keep the tools in their lanes.

  • Files and customization (awareness only) ls /usr/lib/tuned/
  • ls /etc/tuned/
  • cat /etc/tuned/active_profile # often reflects active name; prefer tuned-adm active

Custom profiles can be created under /etc/tuned/ for real admin work. EX200 almost always asks you to activate a shipped profile , not author a new one. If you see active_profile or profile_mode files, treat tuned-adm as the supported interface so the daemon stays consistent.

  • End-to-end exam scenarios
  • Scenario A — Set a named profile

Task: Configure the system to use throughput-performance . systemctl is-active tuned || sudo systemctl enable --now tuned

  • tuned-adm list
  • sudo tuned-adm profile throughput-performance
  • tuned-adm active
  • # Expect: Current active profile: throughput-performance
  • Optional reboot check in practice: sudo reboot

# after login:

  • tuned-adm active
  • systemctl is-enabled tuned
  • Scenario B — Recommended profile tuned-adm recommend
  • # e.g. virtual-guest
  • sudo tuned-adm profile virtual-guest
  • tuned-adm active
  • Scenario C — Confirm before changing
  • Tasks sometimes only ask what is active, or to change only if wrong: tuned-adm active

# If already correct, do not churn. If wrong, switch and re-check.

Scenario D — Tuned not running tuned-adm active

# Error contacting tuned daemon...

  • sudo systemctl enable --now tuned
  • sudo tuned-adm profile balanced
  • tuned-adm active
  • Troubleshooting map
  • Symptom Approach
  • tuned-adm cannot connect systemctl start tuned / enable; check journalctl -u tuned
  • Profile name invalid tuned-adm list for exact spelling; install missing profile package if documented
  • Active reverts after reboot systemctl enable tuned ; re-apply profile; confirm not overwritten by automation
  • verify fails Something changed sysctls manually; re-apply profile or undo conflicting scripts
  • Confusing with power profiles On desktops, other tools exist; for EX200 server objectives, stick to tuned-adm
  • Common traps

Typo in profile name — throughput_performance vs throughput-performance (hyphen).

Changing profile without Tuned running — start/enable the service first.

Assuming tuned-adm profile is temporary — it is the supported persistent selection for Tuned; still ensure the service is enabled for reboot.

Using renice to “satisfy” a tuning-profile task — wrong tool; graders check tuned-adm active .

Editing random sysctls by hand then forgetting Tuned may overwrite them when the profile reapplies.

tuned-adm off by accident — re-apply the required profile.

RHEL 10 notes

Tuned remains the Red Hat-supported profile mechanism on RHEL 10 for this objective. Command names tuned-adm list , active , and profile are the ones to drill until muscle memory. Combine with earlier process skills: if the system is under load, you may still need top / kill / renice for a bad user process and a correct Tuned profile for system policy—they stack, they do not substitute.

Section checkpoint

You should ensure tuned is running, list profiles, read the active profile, apply the exact profile the task requires (or the recommended one), verify with tuned-adm active , and understand that this configuration is system-wide and meant to survive reboot when the service is enabled. Together with process identification, kill signals, and nice/renice, that completes the process-and-tuning slice of Operate running systems for EX200.