tuned-adm on a VPS: Choosing the Right Kernel Profile for Web, Database, and Latency-Sensitive Workloads

Linux ships with hundreds of tunables — CPU governors, scheduler settings, virtual-memory ratios, block-device queue depths — and most VPS owners either leave them at defaults or paste random sysctl values from blog posts. tuned (and its tuned-adm front end) solves the same problem differently: it bundles curated sets of kernel and device settings into named profiles, applies them atomically, and lets you switch between them with one command. This article explains how tuned-adm works on a VPS, which profiles matter for common workloads, and how to verify a profile is actually doing something on virtualized hardware.

Profile tuning is most effective when the underlying plan is honest about its resources — check our VPS provider comparison table to see which hosts give you dedicated vCPUs and full control over kernel settings before you invest time in tuning.

What tuned Actually Does

Under the hood, tuned is a daemon that applies a set of sysctl values, sysfs writes, and device settings defined in a profile directory. Unlike a static /etc/sysctl.conf, tuned can react to events — switching profiles when a device is plugged in or when AC power is lost — and it can disable itself cleanly if a profile conflicts with the running system. On a VPS you care about three things: the CPU governor and scheduler tunings, the virtual-memory behavior, and the block-device queue settings. Profiles bundle all of those coherently.

Installing and Enabling tuned

tuned is a standard package on every major distribution. On Debian/Ubuntu it lives in universe; on RHEL/Rocky/Alma it is in the base repository:

# Debian / Ubuntu
sudo apt update && sudo apt install tuned -y

# RHEL / Rocky / Alma
sudo dnf install tuned -y

# Enable and start the daemon
sudo systemctl enable --now tuned

# See the active profile and the recommended one
sudo tuned-adm active
sudo tuned-adm recommend

The recommend command inspects your hardware and prints the profile the vendor thinks fits — on most cloud instances that will be virtual-guest, which is a good baseline for VPSes and already applied by default on many images.

Profiles That Matter on a VPS

You don’t need all 20+ profiles. These are the ones relevant to virtualized servers:

virtual-guest — the default for cloud/VM images. Disables some power-saving and disk barriers, enables the performance governor if the guest can control it, and otherwise stays conservative. Start here.
throughput-performance — disables power management, sets the CPU governor to performance, increases the sysctl network buffers, and raises the block-device read-ahead. Best for file servers, batch jobs, and high-traffic web servers that want maximum raw throughput.
latency-performance — same CPU focus as throughput-performance but tuned for consistently low latency rather than bulk transfer: it disables transparent huge pages (THP) in some versions, which matters for databases, and tightens scheduler settings for predictable response times.
balanced — the laptop/desktop default; on a VPS it usually leaves power saving enabled, which can cap CPU frequency on hosts that expose cpufreq to the guest. Avoid it on production servers.
network-latency / network-throughput — specialize the kernel network stack for low latency or high throughput. Useful on VPSes running game servers, VoIP, or heavy proxies, but they assume dedicated NICs; verify each setting is accepted by your virtio driver.

# Switch profile (persistent across reboots)
sudo tuned-adm profile latency-performance

# Verify what the profile changed
sudo tuned-adm active
sudo tuned-adm verify   # checks profile integrity

Verifying a Profile Works on Your VPS

Virtualization changes the rules: some profile settings target hardware you don’t control, so the profile may be active without changing anything measurable. Always verify with benchmarks rather than trusting tuned-adm active:

# CPU governor actually in use per core
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor | sort -u

# sysctl values a profile claims to set (example)
sysctl vm.swappiness net.core.rmem_max vm.transparent_hugepages.enabled 2>/dev/null

# Before/after comparison
sysbench cpu run --threads=$(nproc) --cpu-max-prime=20000
sysbench memory run

If the governor shows performance and your sysbench CPU score improves 5–15%, the profile is doing its job. If nothing changed, your host either hides cpufreq (common on shared KVM) or already runs the settings — in that case, the value of tuned is keeping the configuration centralized and revertible rather than the raw speedup.

Custom Profiles: Tuned for Your Stack

When stock profiles are close but not exact, write your own by copying one and overriding a few keys:

# Create a custom profile directory
sudo mkdir -p /etc/tuned/vps-web

# /etc/tuned/vps-web/tuned.conf
[main]
include=throughput-performance

[sysctl]
vm.swappiness=10
vm.dirty_ratio=15
vm.dirty_background_ratio=5
net.core.somaxconn=8192

[cpu]
force_latency=1
governor=performance

# Activate it
sudo tuned-adm profile vps-web
sudo tuned-adm verify

The include directive inherits everything from throughput-performance and your [sysctl] section overrides just the values you care about. Keep custom profiles minimal — every override is a setting you must re-check after kernel or tuned updates.

When Not to Use tuned

tuned is not a fit for every setup. If you use a configuration-management tool that already pins every sysctl value, adding tuned creates two sources of truth that can fight each other. If your provider runs OpenVZ/LXC containers, most sysctls and all cpufreq settings are read-only from inside the container, and tuned will fail to apply them. And if your workload is a single containerized app, Docker’s own resource limits matter more than host profiles. In those cases, a plain /etc/sysctl.d/ file is the simpler tool — see our sysctl tuning guides for the values that matter.

For hosts that expose real kernel control, tuned-adm is the fastest way to move from “default kernel” to “profile matched to workload” with one command and a clean rollback path. Start with virtual-guest, benchmark, try latency-performance or throughput-performance, and keep the one that wins — and if your plan’s vCPUs are too oversubscribed for tuning to help, our VPS comparison table can point you to hosts with dedicated cores.