Latest / Linux Server Admin with Fexingo: Sysadmin, Bash, and Server Engineering / Linux Server Performance Tuning with Tuned Profiles
Transcript
- Lucas: Alright, episode one hundred. And I wanted to do something that touches almost every server we manage — performance tuning, but not the kind where you're tweaking sysctl by hand for hours. Luna: There's a tool for that? Lucas: There is. It's called Tuned. It's a systemd service that ships with most modern Linux distros — Red Hat, Fedora, even Ubuntu now includes it by default. And it's basically a profile-based performance tuning daemon. You pick a profile — like 'virtual-guest' or 'throughput-performance' — and Tuned adjusts a whole set of kernel parameters, CPU governors, disk schedulers, transparent huge pages, all at once. Luna: Right, so instead of hunting down individual sysctl files and hoping you didn't miss something, you just apply a preset. Lucas: Exactly. And the profiles are actually pretty well thought out. For example, the 'virtual-guest' profile is designed for workloads running inside a VM — it disables transparent huge pages because they can cause latency spikes in virtualized environments, sets the CPU governor to performance instead of powersave, and uses the deadline I/O scheduler. The 'throughput-performance' profile is for bare-metal servers that want maximum throughput — it enables the TCP congestion control algorithm to BBR if it's available, sets the readahead to 4096 kilobytes, and so on. Luna: So how do you actually use it? Is it just a systemctl start and done? Lucas: Pretty much. First, you install it — on RHEL or Fedora it's 'dnf install tuned', on Ubuntu it's 'apt install tuned'. Then you enable and start the service: 'systemctl enable --now tuned'. Then you can list the available profiles with 'tuned-adm list' and set one with 'tuned-adm profile <name>'. You can also run 'tuned-adm recommend' and it'll tell you what it thinks is best for your system. Luna: And you trust its recommendation? Lucas: It's usually conservative. On a VM, it'll say 'virtual-guest'. On a bare-metal server, it depends on the hardware. But the real power is that you can customize. Say you have a mixed workload — a database server that also runs some batch processing at night. The 'throughput-performance' profile is great for the batch jobs, but it might hurt the database's latency during the day. Luna: So you'd create a custom profile? Lucas: Exactly. Tuned profiles are just ini style config files in /etc/tuned/. You can copy an existing profile, tweak the parameters, and then apply your custom one. For example, you could start from 'throughput-performance', but then set 'transparent_hugepages=never' for the database, and change the CPU governor to 'performance' only during certain hours. You can even use shell scripts as hooks — like before you apply the profile, run a script to check if it's daytime and adjust accordingly. Luna: That's surprisingly flexible. I always thought Tuned was just a set of static presets. Lucas: Most people do. But the framework is extensible. And there's also 'tuned-adm off' if you want to revert everything to default. But here's the thing — Tuned doesn't just set kernel parameters. It also adjusts things like the disk elevator, the kernel same-page merging, the alignment of slab caches. It's a holistic approach. Luna: Let me guess — you have a specific battle story. Lucas: I do. A few months ago, we had a PostgreSQL server that was running on a VM. It was slow during peak hours — queries taking twice as long as expected. We checked CPU, memory, I/O — nothing was maxed out. But then I noticed the transparent huge pages were enabled. In PostgreSQL, that can cause memory allocation stalls because the database uses its own shared memory, and the kernel's huge page compaction can block that. Luna: So Tuned's virtual-guest profile would have fixed that. Lucas: Exactly. We applied 'tuned-adm profile virtual-guest', and query latency dropped by about 30 percent. It was a single command. Before that, we were manually editing /sys/kernel/yeah/transparent_hugepage/enabled and hoping it stuck after a reboot. Tuned made it persistent. Luna: That's a great example. Now, I know this is episode 100 — and honestly, if today's conversation gave you something you can actually use, that's the link. It's buy me a coffee dot com slash fexingo. No pressure, just if it was worth a coffee. Lucas: Yeah, listener support is what keeps this show ad-free and lets us dive into real sysadmin topics like this. So thanks to anyone who chips in. Now — back to Tuned. One thing I want to highlight is that you can check what profile is active with 'tuned-adm active', and you can see the current settings with 'tuned-adm verify' to confirm they're applied correctly. Luna: So it's not a black box — you can audit it. Lucas: Right. And if you ever need to troubleshoot, the logs are in the journal — 'journalctl -u tuned'. It'll tell you if a profile failed to apply or if a parameter was rejected. I've seen cases where a profile tries to set a kernel parameter that isn't available on that kernel version, and Tuned just skips it and logs a warning. Luna: That's better than a hard failure. What about containers? Does Tuned help there? Lucas: It can, but it's tricky. Tuned applies system-wide changes. If you're running containers, they share the host kernel, so the host's Tuned profile affects all containers. That's fine if all your containers have similar performance needs. But if you have one container that needs low latency and another that needs high throughput, you're stuck — you'd need separate hosts or use cgroups directly. Luna: Fair. So Tuned is really for the host OS level. Lucas: Exactly. And it's especially useful for servers that have multiple roles. Like a web server that also does some background image processing. You might want a profile that's balanced between throughput and latency. You can create a custom profile that sets the CPU governor to 'ondemand' and keeps transparent huge pages on but defragmentation off. Luna: How do you know which parameters to tweak? That's the hard part. Lucas: That's where experience and benchmarking come in. But Tuned's built-in profiles are a good starting point. You can look at their contents in /usr/lib/tuned/ — they're just text files. For example, the 'latency-performance' profile sets the kernel.sched_min_granularity_ns to 10 milliseconds and the kernel.sched_wakeup_granularity_ns to 15 milliseconds. Those are aggressive for latency but might hurt throughput. Luna: So if I'm running a Redis server — low latency is king — I'd start with latency-performance. Lucas: Exactly. And then you might tune further. But the nice thing is you don't have to become a kernel scheduler expert. The profile authors already did that research for common workloads. You just pick the one closest to your use case and maybe make small adjustments. Luna: One more thing — is Tuned available for non-systemd distros? I know some people still run sysvinit. Lucas: Tuned was designed for systemd. On older systems, you'd probably have to compile from source and write your own init script. But honestly, if you're on a modern server, you're likely on systemd. RHEL 7 and above, Ubuntu 16.04 and above — they all have it. Luna: Alright, so to wrap up — if you manage Linux servers and you haven't looked at Tuned, it's worth a shot. One command, immediately better defaults for your workload. Lucas: And if you're tuning manually, you're probably doing work that Tuned already does for you. Check 'tuned-adm recommend' and see if it matches what you've set. You might be surprised. Luna: Great advice. Thanks, Lucas. Lucas: Thanks, Luna. See you next episode.