Choosing and layering performance profiles with tuned on RHEL

Goal

Apply a performance profile matching the workload, and build a small custom variant without duplicating an entire profile.

Prerequisites

The tuned service installed and running (systemctl status tuned).

Steps

1. See every installed profile, with the active one marked:

tuned-adm list

2. See just the current one:

tuned-adm active

3. Let TuneD suggest one based on detected hardware and virtualization:

tuned-adm recommend

4. Apply a profile:

tuned-adm profile throughput-performance

5. Build a custom profile instead of hand-copying a stock one when only a few settings should differ. Create /etc/tuned/myprofile/tuned.conf with a [main] section using the include option, which the manual documents as the mechanism for one profile to load every setting from a named parent before applying its own overrides underneath:

[main]
include=throughput-performance

[sysctl]
vm.swappiness=5

6. Apply the custom profile the same way as any other:

tuned-adm profile myprofile

Expected result

tuned-adm active reports the new profile; effects show up in the subsystem the profile's plugins manage (sysctl values, CPU governor, disk scheduler, depending on what the profile touches). systemctl status tuned and the service's own journal entries confirm it applied without error.

Limits and test basis

Applying a profile takes effect immediately for the settings TuneD's plugins actively manage, without a reboot; check the specific profile's tuned.conf for what it actually touches before assuming a given parameter changed, since a profile only exercises the plugins it references. A custom profile that includes a parent still needs its own directory and its own tuned-adm profile call — it is not automatically picked up as a variant of the parent. Revert with tuned-adm profile <previous-name>, or stop all profile-managed tuning with tuned-adm off. None of the tuned-adm subcommands prompt interactively, so all of this is safe to run from a script.