Learning AlmaLinux - Performance Tuning & Resource Management

#Introduction

In the previous episode, Episode 16, we secured the system and ensured standard compliance. Now we turn to the other side of a good system: performance. A secure but slow server is just as problematic — and so is a server that lets one service wastefully consume all resources while other services starve.

This episode covers three main tools: tuned for matching system profiles to workloads, cgroups v2 for limiting resources per service, and systemd-analyze for reading boot and startup conditions.

#Tuned: Automatic Optimization Profiles

tuned is a daemon that adjusts system parameters (sysctl, scheduler, and others) according to a chosen profile. Instead of manually tuning one parameter at a time, you pick a profile matching the workload.

sudo dnf5 install -y tuned
sudo systemctl enable --now tuned

#Choosing a Profile

tuned-adm active
tuned-adm list

tuned-adm active shows the running profile; list shows all available profiles. For an automatic recommendation:

tuned-adm recommend

#Commonly Used Profiles

sudo tuned-adm profile throughput-performance
tuned-adm active

The throughput-performance profile enables the performance governor, increases network buffers, and adjusts several parameters to maximize output — a common choice for database and application servers.

#Creating a Custom Tuned Profile

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

[main]
summary=My web server tuning
 
[cpu]
governor=performance
 
[sysctl]
vm.swappiness=10
net.core.somaxconn=1024

The file structure: a [main] section, then sections managing components (cpu, sysctl, vm, and others). Activate the custom profile:

sudo tuned-adm profile myweb

tuned-adm active will show myweb. A custom profile can also inherit another profile by adding include= in the [main] section.

#Resource Control with Cgroups v2

In episode 7 we touched on MemoryMax and CPUQuota. Now we dive into how cgroups v2 is the mechanism behind them — the kernel divides processes into groups with resource limits.

#Per-Service Limits

All limits are defined in the systemd unit override:

sudo systemctl edit myapp

[Service]
MemoryMax=1G
MemoryHigh=768M
CPUQuota=100%
TasksMax=512

Explanation of each line:

• MemoryMax=1G — the hard limit; the process is killed if it exceeds it.
• MemoryHigh=768M — the soft limit; throttling happens before the hard limit.
• CPUQuota=100% — equivalent to one full core; 200% means two cores.
• TasksMax=512 — limits the number of tasks (threads/processes) that can be created.

sudo systemctl daemon-reload
sudo systemctl restart myapp
systemd-cgtop

systemd-cgtop is the cgroup equivalent of top — showing real-time resource usage per unit. It's the best tool for seeing whether limits work and who the biggest resource consumers are.

#Checking Usage

systemctl show myapp -p MemoryMax -p CPUQuota
systemctl status myapp

systemctl show displays unit properties — verify that limits are actually applied as expected.

#Analysis with systemd-analyze

Systemd provides analysis commands that turn boot data into insight.

systemd-analyze

systemd-analyze blame

blame sorts services by initialization time — from slowest first. Focus on services taking a disproportionate amount of time:

• Non-critical services that run too early can be delayed.
• Services waiting on devices or network need their dependencies checked.

systemd-analyze critical-chain

critical-chain shows the unit chain that most determines boot time — services on the critical path are the first optimization candidates.

#Comparing Boots

systemd-analyze blame --reverse

By comparing across boots, you can measure whether tuning changes actually speed up startup — data is more reliable than feeling.

#Common Pitfalls

1. Tuning without measuring. Without a baseline, you can't tell whether a change helps. Measure first, change, measure again.
2. Blindly using throughput-performance on a VM. The virtual-guest profile is more appropriate — avoid conflicts with the host.
3. Setting MemoryMax too low. Start big, monitor, lower gradually.
4. Ignoring systemd-cgtop. Real-time usage data is the only way to verify limits are working.
5. Tuning all machines at once. Every workload is different — don't copy-paste profiles without context.

#Conclusion

In this episode 17 you've mastered AlmaLinux performance optimization: selecting tuning profiles with tuned-adm, creating custom profiles, limiting service resources with cgroups v2 via MemoryMax and CPUQuota, and boot and startup analysis with systemd-analyze.

Key takeaways:

• tuned-adm selects a profile by workload: virtual-guest, throughput-performance, latency-performance.
• Custom profiles are written in /etc/tuned/ with [cpu] and [sysctl] sections.
• Cgroups v2 limits resources per service: MemoryMax, MemoryHigh, CPUQuota, TasksMax.
• Monitor with systemd-cgtop and systemctl show for verification.
• systemd-analyze blame and critical-chain find startup bottlenecks.
• Tuning is a measure → change → measure cycle, not a guess.

With performance under control, you're ready to manage modern workloads. In the next episode, Episode 18, we'll cover Containers & Virtualization (Podman, KVM) — rootless containers with Podman, Buildah, and Skopeo, Quadlet for systemd integration, podman-compose, and KVM virtualization with virt-install, virsh, and bridge networking. See you there!