RH134 Chapter 9 — Tuning System Performance

Chapter Objective: Interpret system performance metrics, apply tuned profiles, control per-service resource limits with systemd, and adjust kernel parameters with sysctl.

Key commands: uptime, vmstat, free, tuned-adm, sysctl

Establishing a Performance Baseline

"Slow" is meaningless without something to compare against. Before tuning anything, capture what normal looks like on a given system — typical load, memory usage, and disk activity during regular operation — so a later problem is something you can actually measure against a known baseline rather than guess at.

🔵 Why It Matters Performance tuning without a baseline is just changing settings and hoping. A documented baseline turns "it feels slower" into "load average went from 0.8 to 4.2" — something you can act on with confidence.

Reading Load and Resource Metrics

# Load averages over the last 1, 5, and 15 minutes
uptime

# A snapshot of memory, swap, CPU, and I/O activity
vmstat 2 5   # every 2 seconds, 5 times

# Memory usage in human-readable form
free -h

# Disk I/O statistics per device
iostat -x 2

# CPU usage broken down per core
mpstat -P ALL 2

Metric	What It Tells You
Load average	Roughly, how many processes were runnable or waiting on I/O, averaged over time
%wa (vmstat/top)	Time the CPU spent waiting on I/O — high values often point to a disk bottleneck, not a CPU one
free / available (free -h)	Truly unused memory, versus memory that's reclaimable if needed (buffers/cache)

✅ Tip — Load Average Alone Doesn't Say What's Bottlenecked A high load average could mean CPU contention, disk I/O wait, or both. Pair it with vmstat's %wa column or iostat before concluding the CPU itself is the problem.

tuned and Performance Profiles

tuned is RHEL's adaptive tuning service — instead of manually adjusting dozens of individual kernel parameters, you select a pre-built profile matching your system's role, and tuned applies a coordinated set of settings for it.

# Show the currently active profile
tuned-adm active

# List all available profiles
tuned-adm list

# Switch to a different profile
sudo tuned-adm profile throughput-performance

# Let tuned recommend a profile based on detected hardware/role
tuned-adm recommend

Example Profile	Optimized For
`balanced`	General-purpose default, balancing performance and power savings
`throughput-performance`	Server workloads prioritizing throughput over latency
`latency-performance`	Workloads sensitive to response time
`virtual-guest`	Systems running as a virtual machine guest

✅ Tip — Start With a Profile, Not Manual sysctl Edits A well-chosen tuned profile is almost always a better starting point than hand-tuning individual kernel parameters — it's tested, coordinated, and easy to reason about and reverse.

Controlling Resources with systemd

Beyond system-wide tuning, systemd can cap the resources an individual service is allowed to consume — useful for preventing one runaway service from starving everything else.

# Limit a service to at most 20% of one CPU core
sudo systemctl set-property httpd.service CPUQuota=20%

# Cap maximum memory usage
sudo systemctl set-property httpd.service MemoryMax=512M

# View current resource-related settings for a unit
systemctl show httpd.service -p CPUQuota -p MemoryMax

# Equivalent, permanent configuration inside the unit file
[Service]
CPUQuota=20%
MemoryMax=512M

🔵 Note systemctl set-property applies immediately and can persist depending on how it's used, but for a change you want to survive edits and be clearly documented, adding the directive directly to the unit file (or a drop-in) is the more maintainable approach.

Kernel Tuning with sysctl

# Show all current kernel parameters
sysctl -a

# Show one specific parameter
sysctl vm.swappiness

# Change a parameter temporarily (lost on reboot)
sudo sysctl -w vm.swappiness=10

# Make a change PERMANENT via a config file
echo "vm.swappiness = 10" | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl -p /etc/sysctl.d/99-swappiness.conf

⚠️ Warning — sysctl Is a Precision Tool Kernel parameters interact with each other in ways that aren't always obvious. Change one thing at a time, document why, and prefer a tested tuned profile over ad hoc sysctl edits unless you have a specific, well-understood reason.

Swap and Memory Pressure

# Show swap usage alongside memory
free -h

# Show configured swap devices
swapon --show

# Temporarily disable/enable a swap device
sudo swapoff /dev/sdb2
sudo swapon /dev/sdb2

vm.swappiness (0–100) controls how aggressively the kernel prefers swapping out memory versus reclaiming cache; lower values keep more data in RAM before touching swap.

🔵 Note Heavy sustained swap usage is usually a symptom of insufficient RAM for the workload, not something swappiness tuning alone will fix. Treat persistent swapping as a signal to look at memory sizing or what's consuming memory, not just a knob to twist.

Key Terms for Chapter 9

baseline: A recorded measurement of normal system behavior, used as a comparison point
load average: A rolling measure of runnable/waiting processes over 1, 5, and 15 minutes
tuned: RHEL's adaptive system tuning service, applying coordinated settings via profiles
tuned profile: A pre-built set of tuning settings matched to a particular system role or workload
CPUQuota / MemoryMax: systemd unit properties capping a service's CPU or memory consumption
sysctl: Command and configuration mechanism for viewing and changing kernel parameters at runtime
vm.swappiness: Kernel parameter controlling how aggressively the system swaps memory to disk

Review Questions

Why is a documented performance baseline important before you start tuning anything?
A system shows a high load average. What additional metric would help you tell whether that's CPU-bound or I/O-bound?
What is the advantage of using a tuned profile over manually editing individual sysctl parameters?
Write a command that limits the httpd service to a maximum of 512 MB of memory.
What is the difference between running sysctl -w and adding a setting to a file under /etc/sysctl.d/?
What does vm.swappiness control, and what does a lower value generally mean for behavior?
If a system is swapping heavily on a sustained basis, is adjusting swappiness usually the right long-term fix? Why or why not?