bpftune - Automatic Kernel Tuning with eBPF Cheatsheet
bpftune (by Oracle) is a lightweight daemon that automatically tunes Linux kernel parameters using eBPF. Rather than requiring an admin to guess sysctl values, it observes actual system behavior through eBPF probes — TCP buffer pressure, connection table saturation, memory reclaim — and adjusts the relevant parameters continuously as load changes. Its guiding principle is to be invisible: near-zero overhead, no configuration required, and it deliberately backs off any parameter an administrator has set manually.
Automatic tuning changes kernel behavior on a live system. Trial it on non-critical hosts and watch the logs before broad rollout.
Requirements
- Linux kernel with BPF and BTF support (5.15+ recommended)
- Root privileges (loads eBPF programs, writes sysctls)
Installation
| Platform | Command |
|---|
| Oracle Linux / Fedora | sudo dnf install bpftune |
| From source | git clone https://github.com/oracle/bpftune && make && sudo make install |
| Service | sudo systemctl enable --now bpftune |
| Verify | bpftune -h |
Running
| Command | Description |
|---|
sudo bpftune | Run in the foreground |
sudo bpftune -d | Run as a daemon |
sudo systemctl start bpftune | Start via systemd |
sudo bpftune -s | Show summary of tuners and current state |
journalctl -u bpftune -f | Watch tuning decisions live |
Key Options
| Flag | Effect |
|---|
-d | Daemon mode |
-s | Summary/status output |
-S | Suppress (dry-run) — log what it would change |
-L | Learning mode / legacy behavior |
-r | Rollback changes on exit |
-l LEVEL | Log verbosity |
# See what it would tune without changing anything
sudo bpftune -S -l debug
What It Tunes
| Tuner | Adjusts |
|---|
| TCP buffer | tcp_rmem / tcp_wmem under throughput pressure |
| TCP congestion | Congestion control algorithm selection |
| Connection limits | somaxconn, backlog sizes when queues overflow |
| Neighbour table | ARP/ND table sizes when entries are dropped |
| Route table | Route cache sizing |
| Netns / sysctl | Per-namespace equivalents where applicable |
How the Feedback Loop Works
| Step | Detail |
|---|
| Observe | eBPF probes count drops, overflows, pressure events |
| Decide | If a threshold is repeatedly hit, the parameter is a bottleneck |
| Adjust | Raise the limit incrementally (never unbounded) |
| Re-observe | Confirm the symptom cleared |
| Back off | If an admin set the value manually, leave it alone |
This “observe, nudge, verify” cycle is why it can run continuously without oscillating.
Verifying Its Effect
# What has bpftune changed?
sudo bpftune -s
# Confirm a sysctl it reported adjusting
sysctl net.ipv4.tcp_rmem net.core.somaxconn
# Correlate with the symptom it was fixing
ss -s # socket/queue stats
netstat -s | grep -i drop # drops that triggered tuning
When to Use It
| Scenario | Fit |
|---|
| Variable/unknown workloads | Strong — adapts as load changes |
| Cloud instances of differing sizes | Strong — no per-instance tuning |
| Highly tuned, fixed workload | Weak — your manual values are likely better |
| Strict change control | Use -S dry-run first, or skip |
bpftune vs Manual/Profile Tuning
| Aspect | bpftune | TuneD | Manual sysctl |
|---|
| Model | Continuous, feedback-driven | Static profiles | One-time values |
| Adapts to load | Yes | No | No |
| Config needed | None | Pick a profile | Full expertise |
| Respects manual settings | Yes (backs off) | Overwrites | N/A |
Complements TuneD (broad static profiles) and direct tools like cpupower; bpftune targets network/kernel limits specifically.
Resources
