Red Hat System Administration II · RH134

Chapter 9

Tuning System Performance

Reading metrics · tuned profiles · systemd resource control · sysctl
CIS238RH — Mesa Community College
Read performance metrics, apply tuned profiles, limit per-service resources with systemd, and adjust kernel parameters with sysctl.

Key Commands

  • uptime
  • vmstat
  • free
  • tuned-adm
  • sysctl
  • Record normal load, memory, and disk activity before you tune.
  • Later problems can then be measured against a known reference.
Why It MattersTuning without a baseline is guesswork. A baseline lets you say "load rose from 0.8 to 4.2," not "it feels slow."
# 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
Noteiostat and mpstat come from the sysstat package, which may need to be installed.
MetricWhat It Tells You
Load averageRoughly, 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)
TipA high load average alone doesn't name the bottleneck. Check %wa or iostat before blaming the CPU.

tuned applies a coordinated set of settings, a profile, matched to the system's role.

# 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 ProfileOptimized For
balancedGeneral-purpose default, balancing performance and power savings
throughput-performanceServer workloads prioritizing throughput over latency
latency-performanceWorkloads sensitive to response time
virtual-guestSystems running as a virtual machine guest
TipStart with a tuned profile before hand-editing sysctl. Profiles are tested and easy to reverse.

Cap one service's CPU or memory so a runaway service can't starve the rest.

# 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
Noteset-property applies immediately and persists by default (add --runtime to make it temporary). A unit file or drop-in documents the limit where others will look for it.
# 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
WarningKernel parameters interact in non-obvious ways. Change one at a time, document why, and prefer a tuned profile unless you have a specific need.
# 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) sets how readily the kernel swaps. Lower values keep more data in RAM.

Note — Swapping Is a SymptomSustained heavy swapping usually means the workload needs more RAM. Swappiness alone won't fix that.
baseline
A recorded measurement of normal behavior, used for comparison
load average
Runnable and waiting processes, averaged over 1, 5, and 15 minutes
tuned
RHEL's adaptive tuning service, which applies settings through profiles
tuned profile
A prebuilt set of settings matched to a system role or workload
CPUQuota / MemoryMax
systemd properties that cap a service's CPU or memory
sysctl
Views and changes kernel parameters
vm.swappiness
Kernel parameter controlling how readily memory is swapped to disk
  1. Why is a documented baseline important before tuning?
  2. Which metric helps tell whether a high load average is CPU-bound or I/O-bound?
  3. What advantage does a tuned profile have over manually editing sysctl parameters?
  4. Write a command that limits httpd to a maximum of 512 MB of memory.
  5. How does sysctl -w differ from adding a setting under /etc/sysctl.d/?
  6. What does vm.swappiness control, and what does a lower value mean?
  7. Is adjusting swappiness the right long-term fix for sustained heavy swapping? Why or why not?