RED HAT ENTERPRISE LINUX

Performance Tuning

Optimizing Systems with Tuned Profiles and Process Scheduling

College-Level Course Module | RHEL System Administration

Welcome to this important module on performance tuning in Red Hat Enterprise Linux. Every system has a purpose - web server, database, virtual machine host, desktop workstation - and each benefits from different optimizations. Default settings are a compromise that work reasonably well everywhere but aren't optimal for any specific workload. In this module, you'll learn to use tuned, Red Hat's dynamic adaptive system tuning daemon, to apply workload-specific optimizations with a single command. You'll also master process scheduling - controlling which processes get CPU time and when. Using nice and renice, you can ensure critical processes get priority while background tasks don't interfere. These skills help you extract maximum performance from your hardware and are essential for RHCSA certification.

Learning Objectives

Understand system performance concepts

CPU scheduling, kernel parameters, and tunable settings

Use tuned to apply performance profiles

Select and activate workload-specific tuning profiles

Adjust process priority with nice and renice

Control CPU scheduling priority for individual processes

Monitor and verify performance changes

Use tools to observe the effects of tuning adjustments

We have four main learning objectives. First, you'll understand the concepts behind performance tuning - what can be adjusted, why it matters, and how the Linux scheduler works. This foundation helps you make informed decisions. Second, you'll master tuned, which packages expert knowledge into easy-to-apply profiles. Instead of manually adjusting dozens of kernel parameters, you select a profile matching your workload and tuned handles the details. Third, you'll learn to control process scheduling priority with nice and renice. These commands let you adjust how much CPU time individual processes receive - essential for managing competing workloads. Fourth, you'll verify your changes using monitoring tools. Tuning without measurement is guessing; you need to observe the effects of your adjustments.

Performance Concepts

Performance tuning optimizes system behavior for specific workloads by adjusting kernel parameters, CPU scheduling, I/O behavior, and power management.

CPU Scheduling

How the kernel decides which processes run and for how long. Affects responsiveness vs throughput.

Kernel Parameters

Adjustable values in /proc/sys that control kernel behavior: memory, networking, I/O.

I/O Scheduling

How disk operations are ordered and prioritized. Different schedulers for HDD vs SSD.

Power Management

CPU frequency scaling, sleep states. Trade power consumption for performance.

No free lunch: Tuning involves tradeoffs. Optimizing for throughput may hurt latency. Optimizing for performance increases power consumption.

Performance tuning adjusts how the system allocates resources. There are several areas to consider. CPU scheduling determines which processes run on which CPUs and for how long. The scheduler balances fairness, throughput, and responsiveness - priorities that sometimes conflict. Kernel parameters in /proc/sys control thousands of behaviors: how much memory to use for caching, network buffer sizes, I/O queue depths. Adjusting these can significantly impact performance. I/O scheduling determines the order of disk operations. Different algorithms suit different devices - SSDs don't need the elevator algorithms designed for spinning disks. Power management trades performance for energy savings. Laptop profiles reduce power consumption; server profiles maximize performance. The key insight: there's no universally optimal configuration. Every optimization involves tradeoffs. Faster may mean more power consumption or higher latency. This is why profiles exist - different optimal configurations for different goals.

Introduction to tuned

tuned is a daemon that monitors your system and dynamically applies tuning adjustments. It provides pre-configured profiles for common workloads.

# Check if tuned is installed and running
[root@server ~]# systemctl status tuned
● tuned.service - Dynamic System Tuning Daemon
     Loaded: loaded (/usr/lib/systemd/system/tuned.service; enabled)
     Active: active (running) since Mon 2024-01-20 10:00:00 EST

# Install tuned if not present
[root@server ~]# dnf install tuned

# Enable and start tuned
[root@server ~]# systemctl enable --now tuned

# Check current active profile
[root@server ~]# tuned-adm active
Current active profile: virtual-guest

Pre-installed: tuned is installed and enabled by default on RHEL. It automatically selects a profile based on detected hardware and virtualization.

tuned is Red Hat's solution for making performance tuning accessible. Instead of requiring deep kernel knowledge, it packages expert configurations into profiles you can apply with a single command. tuned runs as a daemon (background service). It applies settings when activated and can dynamically adjust based on system activity. On RHEL, tuned is installed and enabled by default. Check with systemctl status tuned. If somehow missing, install with dnf install tuned. The tuned-adm command is your interface to tuned. The "active" subcommand shows which profile is currently applied. tuned automatically detects if the system is a virtual machine and selects an appropriate profile. Physical servers might get a different default than VMs. This auto-detection is smart but not always optimal - you often want to manually select a profile matching your actual workload.

Available Profiles

# List all available profiles
[root@server ~]# tuned-adm list
Available profiles:
- accelerator-performance     - Performance for NVIDIA GPUs
- balanced                    - Balance performance and power
- desktop                     - Desktop system optimization
- hpc-compute                 - High-performance computing
- intel-sst                   - Intel Speed Select Technology
- latency-performance         - Low latency performance
- network-latency             - Low latency network tuning
- network-throughput          - High throughput networking
- optimize-serial-console     - Serial console optimization
- powersave                   - Maximum power saving
- throughput-performance      - High throughput performance
- virtual-guest               - Virtual machine guest
- virtual-host                - Virtual machine host
Current active profile: balanced

# Get recommendation based on system
[root@server ~]# tuned-adm recommend
virtual-guest

tuned-adm list shows all available profiles. RHEL includes profiles for common scenarios. The recommend subcommand suggests a profile based on detected hardware and whether the system is virtualized. It's a good starting point, but you should choose based on actual workload, not just hardware. Key profiles to know: balanced is the safe default - reasonable performance without excessive power use. throughput-performance maximizes throughput, good for batch processing and servers. latency-performance minimizes response time, good for real-time and interactive applications. virtual-guest optimizes for running as a VM. virtual-host optimizes for running VMs (as a hypervisor). powersave minimizes power consumption, useful for laptops and energy-conscious environments. network-latency and network-throughput focus specifically on network optimization for different needs. Profile names are descriptive - choose based on what matters for your workload.

Common Profiles

Choose by workload: Database server? throughput-performance. Trading platform? latency-performance. Cloud VM? virtual-guest.

Let's understand what each major profile optimizes for. balanced is the diplomatic choice - it won't break anything and works reasonably everywhere. It balances power consumption with performance, making some compromises in both directions. throughput-performance goes all-in on moving data. It disables power saving features, keeps CPUs at maximum frequency, and tunes I/O for large sequential operations. Great for batch processing, database servers handling large queries, file servers. latency-performance minimizes response time. Every millisecond matters - CPUs never slow down, scheduling favors quick response over fairness. Use for trading systems, real-time audio/video, interactive applications where delay is unacceptable. powersave does the opposite - aggressive power saving at the cost of performance. CPUs run slow, devices sleep aggressively. Use for laptops on battery or when electricity cost matters more than speed. virtual-guest recognizes you're in a VM and doesn't fight the hypervisor. Reduces overhead that makes sense on physical hardware but wastes cycles in VMs. desktop optimizes for interactive use - the foreground application gets priority for a responsive feel.

Applying Profiles

# Switch to a different profile
[root@server ~]# tuned-adm profile throughput-performance
No current profile.   # (or shows previous profile)

# Verify the change
[root@server ~]# tuned-adm active
Current active profile: throughput-performance

# Check what the profile actually does
[root@server ~]# tuned-adm profile_info throughput-performance
Profile name:
throughput-performance

Profile summary:
Broadly applicable tuning that provides excellent performance
across a variety of common server workloads.

Profile description:
...

# Turn off tuned (restore defaults)
[root@server ~]# tuned-adm off

# Reactivate with recommended profile
[root@server ~]# tuned-adm profile $(tuned-adm recommend)

Immediate effect: Profile changes take effect immediately. No reboot required. Settings persist across reboots.

Profile Details

# View profile configuration files
[root@server ~]# ls /usr/lib/tuned/
balanced                  network-latency        virtual-guest
desktop                   network-throughput     virtual-host
latency-performance       powersave
throughput-performance    ...

# Examine a profile's configuration
[root@server ~]# cat /usr/lib/tuned/throughput-performance/tuned.conf
[main]
summary=Broadly applicable tuning for excellent performance

[cpu]
governor=performance
energy_perf_bias=performance
min_perf_pct=100

[disk]
readahead=>4096

[sysctl]
kernel.sched_min_granularity_ns=10000000
kernel.sched_wakeup_granularity_ns=15000000
vm.dirty_ratio=40
vm.dirty_background_ratio=10
vm.swappiness=10

Profiles are layered: Many profiles inherit from others. throughput-performance extends balanced with throughput-specific overrides.

Understanding profile internals helps you make informed choices and create custom profiles. Profiles live in /usr/lib/tuned/profilename/. Each contains a tuned.conf file defining the settings. Looking at throughput-performance, we see several sections. The [cpu] section sets the CPU governor to "performance" (always maximum frequency) and configures energy/performance bias toward performance. The [disk] section increases readahead for sequential I/O performance. The [sysctl] section sets kernel parameters. These are the same values you could set manually in /proc/sys, but tuned handles it for you. Key settings here: sched parameters affect scheduler behavior, vm.dirty_ratio controls write caching, vm.swappiness affects swap usage. Profiles often inherit from parent profiles using include=profile_name. This creates a hierarchy where specific profiles only override what they need to change from a base profile.

Custom Profiles

# Create directory for custom profile
[root@server ~]# mkdir /etc/tuned/my-web-server

# Create custom profile based on throughput-performance
[root@server ~]# cat > /etc/tuned/my-web-server/tuned.conf << 'EOF'
[main]
summary=Custom profile for web servers
include=throughput-performance

[sysctl]
# Increase network buffers for high-traffic web server
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216

# More file handles for many connections
fs.file-max=2097152

[vm]
# Transparent huge pages for better memory performance
transparent_hugepages=always
EOF

# Activate custom profile
[root@server ~]# tuned-adm profile my-web-server

# Verify
[root@server ~]# tuned-adm active
Current active profile: my-web-server

Location matters: Custom profiles go in /etc/tuned/ (survives updates). System profiles are in /usr/lib/tuned/ (overwritten on updates).

You can create custom profiles for specific needs. Custom profiles go in /etc/tuned/profilename/, which survives system updates. Never modify files in /usr/lib/tuned/ - they're overwritten on package updates. The include= directive lets you start from an existing profile and only specify changes. This example inherits throughput-performance and adds web server specific tuning. Network buffer increases help high-traffic web servers handle many concurrent connections. The tcp_rmem and tcp_wmem settings expand TCP buffer sizes. fs.file-max increases the maximum number of file handles - each network connection uses a file descriptor. Transparent huge pages can improve memory performance for memory-intensive applications. After creating the profile directory and tuned.conf, activate it with tuned-adm profile. Your custom profile appears in tuned-adm list alongside the system profiles. This is how you can codify organization-specific tuning and apply it consistently across servers.

Process Scheduling

The Linux scheduler decides which processes run on which CPUs and for how long. Priority influences these decisions - higher priority processes get more CPU time.

Linux Scheduling Classes (highest to lowest priority)

SCHED_FIFO SCHED_RR ← Real-time (priority 1-99)

SCHED_OTHER ← Normal processes (nice -20 to +19)

SCHED_BATCH SCHED_IDLE ← Background tasks

For most tasks: You'll use nice and renice to adjust priority within SCHED_OTHER. Real-time scheduling requires special privileges and care.

Linux uses a sophisticated scheduler to share CPUs among processes. Understanding the basics helps you use nice and renice effectively. The scheduler has multiple scheduling classes. Real-time classes (SCHED_FIFO, SCHED_RR) have highest priority - they preempt everything else. These are for truly time-critical tasks like industrial control. Misuse can lock up your system. SCHED_OTHER (also called SCHED_NORMAL) is where most processes live. Within this class, the "nice" value determines relative priority. Lower nice = higher priority. Range is -20 (highest) to +19 (lowest). Default is 0. SCHED_BATCH is for CPU-intensive batch jobs that shouldn't impact interactive performance. SCHED_IDLE runs only when nothing else needs the CPU. For day-to-day administration, you'll adjust nice values within SCHED_OTHER. This is safe and doesn't require special privileges for lowering priority. Raising priority (lower nice value) requires root.

Understanding Nice Values

Nice Value Scale

-20

Highest
Priority

-10

High
Priority

Normal
(Default)

+10

Low
Priority

+19

Lowest
Priority

# View nice values of running processes
[student@server ~]$ ps -el | head
F S   UID     PID    PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
4 S     0       1       0  0  80   0 -  43812 ep_pol ?        00:00:02 systemd
1 S     0       2       0  0  80   0 -      0 kthrea ?        00:00:00 kthreadd

# View with top (NI column)
[student@server ~]$ top
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1234 student   20   0  225832   4608   3584 R  95.0   0.1   5:23.45 compile
 5678 mysql     20   0 1256320 524288  16384 S  45.0  12.8   2:15.67 mysqld

The name "nice": A process with high nice value is being "nice" to others by accepting lower priority. Low nice = not nice, demanding more CPU.

The nice value scale is counterintuitive at first. Lower numbers mean HIGHER priority. The name helps: a "nice" process yields to others, so high nice values mean low priority. The range is -20 to +19, with 0 as default. Negative values require root privileges to set - you're claiming more than your fair share. Positive values can be set by any user - you're being generous by accepting less. ps -el shows nice values in the NI column. top also shows them. The PR (priority) column in top shows the actual kernel priority, which is 20 + nice value for normal processes. So nice 0 shows as priority 20, nice -20 shows as priority 0. In the example, both processes have nice value 0 (the NI column shows 0). The compile process is using 95% CPU. If we want mysqld to get more CPU time, we could lower its nice value or raise the compile process's nice value.

Using nice

# Start a process with higher nice value (lower priority)
[student@server ~]$ nice -n 10 ./long_running_script.sh
# Process runs at nice 10 - lower priority than default

# Start at nice 19 (lowest priority)
[student@server ~]$ nice -n 19 find / -name "*.log" 2>/dev/null

# Default nice command adds 10
[student@server ~]$ nice ./backup.sh    # Runs at nice 10

# Start with higher priority (lower nice value) - requires root
[root@server ~]# nice -n -10 /opt/critical-app/start.sh
# Process runs at nice -10 - higher priority than default

# Verify the nice value
[student@server ~]$ nice -n 15 bash -c 'ps -o pid,ni,comm -p $$'
    PID  NI COMMAND
  12345  15 bash

# Nice value is inherited by child processes
[student@server ~]$ nice -n 10 bash    # Shell and all commands in it run at nice 10

Requires root: Only root can set negative nice values (higher priority). Regular users can only lower their priority (increase nice value).

nice starts a new process with a specified nice value. The syntax is nice -n VALUE command. Common pattern: long-running background tasks that shouldn't impact interactive work get nice 10-19. The system remains responsive even while these tasks run. Without -n, nice defaults to adding 10 to the current nice value. From a normal shell (nice 0), "nice command" runs at nice 10. Negative nice values require root. This is a security measure - otherwise any user could claim all CPU time by running at nice -20. Child processes inherit nice values. If you start a shell with nice -n 10, everything you run in that shell also runs at nice 10. This is useful for batch processing sessions. In the examples: a CPU-intensive find runs at nice 19 so it doesn't slow down other work. A backup script runs at nice 10 for the same reason. A critical application runs at nice -10 (requiring root) to ensure it gets CPU time even when the system is busy.

Using renice

# Change nice value of running process by PID
[root@server ~]# renice -n 10 -p 1234
1234 (process ID) old priority 0, new priority 10

# Lower nice value (increase priority) - requires root
[root@server ~]# renice -n -5 -p 5678
5678 (process ID) old priority 0, new priority -5

# Change nice for all processes owned by a user
[root@server ~]# renice -n 5 -u student
1000 (user ID) old priority 0, new priority 5

# Change nice for all processes in a process group
[root@server ~]# renice -n 10 -g 1234

# Users can only increase their own processes' nice value
[student@server ~]$ renice -n 15 -p 1234    # OK if student owns PID 1234
[student@server ~]$ renice -n -5 -p 1234    # FAILS - can't lower nice without root
renice: failed to set priority for 1234 (process ID): Permission denied

# Find PID and renice in one step
[root@server ~]# renice -n 10 -p $(pgrep -f backup.sh)

renice changes the nice value of running processes. Unlike nice (which starts a new process), renice modifies existing processes. The syntax is renice -n VALUE -p PID for a specific process. You can also use -u USER to affect all processes owned by a user, or -g PGID for a process group. Same privilege rules apply: anyone can increase nice value (lower priority) for their own processes. Only root can decrease nice value (raise priority) or modify other users' processes. Practical scenarios: A runaway process is consuming CPU. Use renice to lower its priority while you investigate. A critical database is competing with batch jobs. Raise the database's priority. The last example shows combining renice with pgrep to find the PID automatically. This is useful when you know the process name but not the PID.

Viewing Priorities

# ps with nice values
[student@server ~]$ ps -eo pid,ni,pri,comm --sort=-ni | head
    PID  NI PRI COMMAND
   1234  19   0 backup
   5678  15   5 indexer
   9012  10  10 batch_job
      1   0  20 systemd
    567  -5  25 database

# top - interactive view (press 'r' to renice)
[student@server ~]$ top
top - 14:30:00 up 5 days,  3:22,  2 users,  load average: 2.50, 2.10, 1.95
Tasks: 215 total,   3 running, 212 sleeping,   0 stopped,   0 zombie
%Cpu(s): 45.2 us,  5.1 sy,  0.0 ni, 49.0 id,  0.3 wa,  0.2 hi,  0.2 si
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1234 student   39  19  225832   4608   3584 R  25.0   0.1   5:23.45 backup
 5678 mysql     15  -5 1256320 524288  16384 S  35.0  12.8   2:15.67 mysqld

# htop - more interactive (easier renice with F7/F8)
[root@server ~]# dnf install htop
[root@server ~]# htop

top shortcuts: Press r to renice a process. Enter PID, then new nice value. Press k to kill. Press h for help.

Monitoring tools show nice values and help you identify processes needing adjustment. ps with custom format shows exactly the columns you need. The -eo option specifies output columns: pid, ni (nice), pri (priority), comm (command). Sort by nice value to see extremes. top provides an interactive view. The NI column shows nice values, PR shows priority. The example shows mysqld running at nice -5 (higher priority, PR 15) and backup at nice 19 (lower priority, PR 39). Within top, press 'r' to renice a process - you're prompted for PID and new nice value. Press 'k' to send signals (kill). htop is an enhanced interactive process viewer. It has easier controls: F7 decreases nice (higher priority), F8 increases nice (lower priority). Color coding makes it easier to see what's happening. Install it with dnf install htop.

Practical Examples

# Scenario 1: Run backup without impacting production
[root@server ~]# nice -n 19 tar -czvf /backup/full-backup.tar.gz /data/

# Scenario 2: Database competing with batch jobs - prioritize database
[root@server ~]# renice -n -10 -p $(pgrep mysqld)
[root@server ~]# renice -n 15 -p $(pgrep batch_processor)

# Scenario 3: User's compile job consuming too much CPU
[root@server ~]# renice -n 10 -u developer

# Scenario 4: Start development shell at low priority
[developer@server ~]$ nice -n 10 bash
[developer@server ~]$ make -j8     # Compile at nice 10

# Scenario 5: Critical monitoring must always run
[root@server ~]# nice -n -15 /opt/monitoring/agent start

# Scenario 6: Bulk indexing job in Elasticsearch (don't impact searches)
[root@server ~]# nice -n 10 /usr/share/elasticsearch/bin/reindex.sh

Pattern: Background/batch tasks get nice 10-19. Critical services get nice -5 to -15. Normal services stay at 0.

These examples show common real-world scenarios. Backup jobs should never impact production. Running tar at nice 19 means it only gets CPU time when nothing else needs it. Backup takes longer but production stays responsive. When a database competes with batch processing, raise database priority (lower nice) and lower batch priority (higher nice). The database handles user requests; batch can wait. If a specific user is impacting others, renice all their processes. This is useful when developers run resource-intensive builds. Starting a shell at low priority means everything you run inherits that priority. Useful for development work that shouldn't impact others. Critical monitoring or control systems may need higher priority to ensure they always run, even on a busy system. Bulk operations in databases or search engines should run at reduced priority so normal queries aren't impacted.

Real-time with chrt

chrt changes the scheduling policy and priority of processes. Real-time scheduling (SCHED_FIFO, SCHED_RR) is for time-critical applications.

# View current scheduling policy and priority
[student@server ~]$ chrt -p 1234
pid 1234's current scheduling policy: SCHED_OTHER
pid 1234's current scheduling priority: 0

# Run process with SCHED_FIFO (first-in, first-out real-time)
[root@server ~]# chrt -f 50 /opt/realtime-app/start

# Run with SCHED_RR (round-robin real-time)
[root@server ~]# chrt -r 50 ./time-critical-task

# Change running process to real-time
[root@server ~]# chrt -f -p 50 1234

# Set to SCHED_BATCH (CPU-intensive batch jobs)
[root@server ~]# chrt -b 0 ./batch_processor

# Set to SCHED_IDLE (only when system is idle)
[root@server ~]# chrt -i 0 ./background_indexer

⚠ Caution: Real-time processes can lock up your system if they don't yield the CPU. Use carefully and test thoroughly. Requires root.

chrt goes beyond nice to control scheduling policy itself. This is advanced territory - most administration uses nice/renice, but you should know chrt exists. SCHED_FIFO runs until it yields or blocks, then the next SCHED_FIFO runs. No time slicing. SCHED_RR is round-robin among real-time processes with the same priority. Time slices rotate. Both completely preempt non-real-time processes. A runaway real-time process will lock out everything else, including your SSH session. Use only for genuinely time-critical applications: industrial control, audio/video processing, financial trading. SCHED_BATCH tells the scheduler this is a CPU-bound batch job. It won't get quick wake-up latency but runs efficiently. SCHED_IDLE runs only when the system has nothing else to do. Even nice 19 processes run before SCHED_IDLE. The numbers for real-time (1-99) are the real-time priority. Higher is higher priority. This is separate from nice values.

Monitoring Performance

# CPU and system overview
[student@server ~]$ top
[student@server ~]$ htop

# System resource summary
[student@server ~]$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 524288  65536 1048576    0    0    50   100  500 1000 45  5 49  1  0

# I/O statistics
[student@server ~]$ iostat -xz 1
Device      r/s     w/s   rkB/s   wkB/s  %util
sda        10.5    25.3   420.0  1012.0   15.2

# Check current CPU governor
[student@server ~]$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

# Verify tuned settings were applied
[root@server ~]# sysctl vm.swappiness
vm.swappiness = 10

# Check tuned's actual changes
[root@server ~]# tuned-adm verify
Verification succeeded, current system settings match the preset profile.

Verification is essential - tuning without measurement is guessing. top and htop show real-time process information including CPU usage, memory, and nice values. They're your first tool for seeing what's consuming resources. vmstat shows system-wide statistics: processes running, memory usage, swap activity, I/O, and CPU breakdown. The 1 5 arguments mean report every 1 second, 5 times. Watch the columns: high 'wa' (wait) suggests I/O bottleneck, high 'us' (user) means CPU-bound work. iostat shows disk I/O. High %util on a disk suggests I/O bottleneck. The -x option shows extended statistics, -z skips idle devices. Check that tuned actually changed settings. The CPU governor should match the profile (performance for throughput profiles, powersave for power profiles). sysctl shows kernel parameters - verify they match the profile's settings. tuned-adm verify confirms the current system state matches the active profile. If it doesn't, something might have overridden tuned's settings.

Combined Approach

Use tuned for system-wide optimization and nice/renice for process-specific adjustments. They work together, not instead of each other.

tuned (System-Wide)

CPU governor and frequency
Kernel scheduling parameters
I/O scheduler selection
Network buffer sizes
Virtual memory behavior
Power management policies

nice/renice (Per-Process)

Individual process priority
User's total CPU share
Background vs foreground
Critical vs batch processes
Runtime adjustments
Temporary overrides

# Example: Database server optimization
[root@dbserver ~]# tuned-adm profile throughput-performance  # System-wide
[root@dbserver ~]# renice -n -5 -p $(pgrep mysqld)          # Prioritize DB
[root@dbserver ~]# nice -n 15 ./backup.sh                   # Deprioritize backup

tuned and nice work at different levels and complement each other. tuned optimizes system-wide settings: how the kernel schedules all processes, how I/O is handled, power management policies. These are global settings affecting everything. nice and renice fine-tune within that framework: which specific processes get more or less CPU time relative to each other. They work within whatever parameters tuned has set. Example workflow for a database server: First, apply throughput-performance profile. This optimizes the kernel for high throughput - CPU at max speed, larger I/O operations, more caching. Second, give MySQL higher priority with renice. Even with an optimized system, when backup competes with queries, MySQL should win. Third, run backups at low priority. They'll complete eventually but won't impact database performance. This layered approach gives you both optimal global settings and precise control over specific workloads.

Troubleshooting

# tuned not applying settings?
[root@server ~]# systemctl status tuned
[root@server ~]# tuned-adm verify
Verification failed, current system settings differ from the preset profile.
We checked the following:

# Check for conflicts with other tools
[root@server ~]# systemctl status power-profiles-daemon   # May conflict

# Process not respecting nice value?
[student@server ~]$ ps -eo pid,ni,comm -p 1234
# Check if process is I/O bound (nice only affects CPU)

# System still slow after tuning?
[student@server ~]$ vmstat 1
# High 'b' column = processes blocked on I/O
# High 'wa' = CPU waiting on I/O (not a CPU problem)
# High 'si'/'so' = swap activity (memory problem)

# Identify the bottleneck
[student@server ~]$ top                 # CPU bound?
[student@server ~]$ iostat -xz 1        # Disk I/O bound?
[student@server ~]$ free -h             # Memory bound?
[student@server ~]$ ss -s               # Network connections?

Nice only affects CPU: If a process is waiting for disk I/O or network, changing its nice value won't help. Identify the actual bottleneck first.

When tuning doesn't seem to work, systematic troubleshooting helps. If tuned settings aren't applying, check the service is running and verify settings. Other tools might conflict - power-profiles-daemon on desktops can override tuned's power settings. If nice values seem ineffective, understand that nice only affects CPU scheduling. A process waiting on disk I/O or network won't run faster with higher priority - it's not competing for CPU, it's waiting for something else. Identify the actual bottleneck before tuning. vmstat shows where time is spent: high 'wa' means I/O wait (disk is slow), high 'si/so' means swapping (need more RAM), high 'us' means CPU bound (nice values help here). Match your tuning to the bottleneck: CPU bound - nice values help, throughput-performance profile helps. I/O bound - different I/O scheduler, faster disks, more RAM for caching. Memory bound - more RAM, reduce swappiness, tune application memory use.

Best Practices

✓ Do

Choose tuned profile based on workload
Monitor before and after tuning
Use nice for background/batch jobs
Document profile choices and reasons
Test changes in non-production first
Verify settings actually applied
Start conservative, adjust gradually
Identify bottleneck before tuning

✗ Don't

Tune without measuring
Use real-time scheduling casually
Give everything high priority
Ignore the actual bottleneck
Assume one profile fits all workloads
Modify /usr/lib/tuned/ (use /etc/tuned/)
Forget nice only affects CPU scheduling
Skip verification after changes

Measure first: Before tuning, establish baseline metrics. After tuning, measure again. Without data, you can't know if changes helped.

Following best practices ensures effective, safe tuning. Choose profiles based on actual workload, not guesses. A web server needs different optimization than a database. Always monitor before and after - establish baselines, then measure the effect of changes. Without data, you're guessing. Use nice for background tasks. Backups, indexing, log processing - anything that shouldn't impact interactive performance gets positive nice values. Document your choices. Why did you pick throughput-performance? What nice values are set for which processes? Future you (or your replacement) will appreciate notes. Test in non-production. Some settings might cause problems you didn't anticipate. Better to discover in test than production. Don't give everything high priority - that defeats the purpose. If everything is high priority, nothing is. Don't use real-time scheduling unless you really need it and understand the risks. Always identify the actual bottleneck first. Tuning the wrong thing wastes effort.

Key Takeaways

tuned: System-wide profiles. tuned-adm profile NAME to apply. tuned-adm list to see options.

Profiles: balanced (default), throughput-performance, latency-performance, virtual-guest, powersave. Match to workload.

nice/renice: Values -20 to +19 (lower = higher priority). nice -n 10 cmd to start, renice -n 10 -p PID to change.

Verify: Use top, vmstat, tuned-adm verify. Measure before and after. Identify bottleneck first.

LAB EXERCISES

List available tuned profiles and check the active profile
Apply the throughput-performance profile and verify settings
Start a process with nice value 15, verify with ps
Use renice to change a running process's priority
Create a custom tuned profile inheriting from balanced
Monitor system with top and vmstat while changing profiles

Next: Managing SELinux Security

Let's summarize the key performance tuning skills. tuned provides system-wide optimization through profiles. Use tuned-adm to list profiles, check the active profile, and switch profiles. Changes take effect immediately and persist across reboots. Know the key profiles: balanced for general use, throughput-performance for servers and batch processing, latency-performance for real-time and interactive applications, virtual-guest for VMs, powersave for power conservation. nice and renice control individual process priority. The scale is -20 (highest) to +19 (lowest), with 0 as default. Regular users can only lower priority (increase nice). Root can raise priority (decrease nice). Always measure and verify. Use top, vmstat, iostat to understand system behavior. Use tuned-adm verify to confirm settings applied. Establish baselines before tuning, measure after, and identify the actual bottleneck before making changes. Your lab exercises give you hands-on practice with these essential skills.