Learn Rocky Linux - Performance Tuning & Resource Control

#Introduction

In the previous episode 16, you secured communication with TLS. Now it's time to make sure your server works as efficiently as possible. Performance tuning isn't about overclocking — it's about matching the operating system's behavior to the workload's character: a database server needs different settings than a file server or a web application. Rocky Linux provides tools that make tuning more structured: tuned for workload profiles, sysctl for kernel parameters, and systemd resource control with cgroups v2 to limit resources per service.

#Performance Tuning with Tuned

#The Profile Concept

tuned is a daemon that groups performance settings into profiles — one set of kernel parameters tailored to a specific workload type. Instead of changing ten sysctl settings one by one, you simply pick the profile that fits.

systemctl status tuned

tuned-adm list

#Selecting and Applying Profiles

tuned-adm active

tuned-adm profile throughput-performance

tuned-adm recommend

Some common profiles: throughput-performance for servers that prioritize throughput, latency-performance for latency-sensitive workloads, and virtual-guest for VMs — a profile that is often selected automatically on cloud installations.

#Custom Profiles

For specific needs, create your own profile in /etc/tuned/:

mkdir -p /etc/tuned/myworkload
cat > /etc/tuned/myworkload/tuned.conf <<'EOF'
[main]
include=throughput-performance
 
[sysctl]
vm.swappiness=10
net.core.somaxconn=65535
EOF

tuned-adm profile myworkload

A custom profile inherits a base profile (include) and then overrides it with specific settings.

#Kernel Parameters and Sysctl

#Swappiness and File Max

sysctl vm.swappiness
sysctl fs.file-max

sysctl -w vm.swappiness=10

vm.swappiness controls the kernel's tendency to use swap. A low value (10) keeps applications in RAM; a high value is useful for systems that deliberately use swap. fs.file-max limits the global number of file descriptors — often raised for servers with many connections.

#Kernel Boot Parameters

Besides runtime sysctl, kernel parameters can be passed at boot. Add them through the grubby you learned about in episode 10:

grubby --update-kernel=ALL --args="sysrq_always_enabled=1"

grubby --update-kernel=ALL --remove-args="sysrq_always_enabled=1"

Changes only take effect after a reboot — unlike sysctl, which applies immediately.

#Sysctl Persistence

Remember the pattern from episode 10: write sysctl changes to /etc/sysctl.d/ so they survive reboots:

echo 'vm.swappiness = 10' > /etc/sysctl.d/99-tuning.conf
sysctl --system

#Resource Control with Systemd

#The Cgroups Concept

cgroups v2 is the kernel mechanism for dividing and limiting resources (CPU, memory, IO) per group of processes. Systemd integrates cgroups natively — every service unit automatically becomes a member of a cgroup.

systemctl status httpd

systemctl show -p MemoryCurrent -p CPUUsageNS httpd

#Limiting a Service's Resources

Systemd provides resource control directives directly in the unit file or in an override:

systemctl edit httpd

[Service]
CPUQuota=50%
MemoryMax=512M
IOWeight=200

systemctl daemon-reload
systemctl restart httpd

• CPUQuota=50% — the service may use at most one full core of two.
• MemoryMax=512M — a hard memory limit; if exceeded, the process is killed.
• IOWeight=200 — relative I/O priority compared to other services.

This combination protects the server: one uncontrolled application cannot consume the resources of the whole system.

#MemoryLow for Priority

For critical services, use MemoryLow — a memory guarantee that other processes cannot take away:

systemctl edit sshd

[Service]
MemoryLow=64M

A service with MemoryLow is guaranteed memory even under system pressure — a last line of defense so SSH doesn't die along with everything else.

#Boot Analysis with Systemd-Analyze

#Boot Speed

systemd-analyze

systemd-analyze blame

systemd-analyze blame shows the units that take the longest to start at boot — a starting point for speeding up server startup time.

#Critical Chain

systemd-analyze critical-chain

systemd-analyze critical-chain multi-user.target

This output shows which units most slow down reaching a particular target — useful when optimizing service start order.

#Closing

In this episode 17, you mastered Rocky Linux performance tuning: tuned profiles for different workloads, kernel parameter adjustment with sysctl and boot parameters via grubby, systemd resource control with cgroups v2 through CPUQuota, MemoryMax, and IOWeight, and boot time analysis with systemd-analyze.

Key takeaways:

• Use tuned with profiles like throughput-performance or latency-performance, refined through custom profiles.
• vm.swappiness and fs.file-max are the sysctl parameters most often changed.
• Persist sysctl changes in /etc/sysctl.d/ so they survive reboots.
• Systemd resource control with cgroups v2 protects the server from uncontrolled applications.
• systemd-analyze blame and critical-chain help find boot bottlenecks.

In the next episode 18, we will discuss bootable containers (bootc) and image mode — the concept of the operating system as a container image, the bootc switch command, atomic updates, and building custom OS images with bootc-image-builder. You've mastered the static server; now it's time for a system that can be imaged and deployed like a container!