bpftune – Automatic Kernel Tuning with eBPF Cheatsheet
bpftune (von Oracle) ist ein leichtgewichtiger Daemon, der automatisch Linux Kernel Parameter mit eBPF tuned. Statt dass ein Admin Sysctl-Werte erraten muss, beobachtet er tatsächliches System-Verhalten durch eBPF Probes – TCP Buffer Druck, Connection Table Sättigung, Memory Reclaim – und passt die relevanten Parameter kontinuierlich an, wenn sich die Last ändert. Seine leitende Philosophie ist unsichtbar zu sein: nahe Null Overhead, keine Konfiguration erforderlich, und es zieht sich absichtlich von jedem Parameter zurück, den ein Administrator manuell gesetzt hat.
Automatisches Tuning ändert Kernel-Verhalten auf einem lebenden System. Probieren Sie es auf nicht-kritischen Hosts und schauen Sie auf die Logs, bevor Sie es breiter einführen.
Anforderungen
- Linux Kernel mit BPF und BTF Support (5.15+ empfohlen)
- Root Privilegien (lädt eBPF Programme, schreibt Sysctls)
Installation
| Plattform | Befehl |
|---|
| Oracle Linux / Fedora | sudo dnf install bpftune |
| Aus Quelle | git clone https://github.com/oracle/bpftune && make && sudo make install |
| Service | sudo systemctl enable --now bpftune |
| Überprüfen | bpftune -h |
Laufen
| Befehl | Beschreibung |
|---|
sudo bpftune | Führen Sie im Vordergrund aus |
sudo bpftune -d | Führen Sie als Daemon aus |
sudo systemctl start bpftune | Starten Sie via Systemd |
sudo bpftune -s | Zeigen Sie Zusammenfassung von Tunern und aktuellem Zustand |
journalctl -u bpftune -f | Schauen Sie Tuning-Entscheidungen live |
Wichtige Optionen
| Flag | Effekt |
|---|
-d | Daemon-Modus |
-s | Zusammenfassung/Status-Ausgabe |
-S | Unterdrücken (Dry-run) – log was es würde ändern |
-L | Learning Mode / Legacy Verhalten |
-r | Rollback Änderungen beim Exit |
-l LEVEL | Log Verbosität |
# Sehen Sie, was es tunen würde ohne irgendetwas zu ändern
sudo bpftune -S -l debug
Was es tuned
| Tuner | Passt an |
|---|
| TCP Buffer | tcp_rmem / tcp_wmem unter Durchsatz-Druck |
| TCP Congestion | Congestion Control Algorithmus Auswahl |
| Connection Limits | somaxconn, Backlog Größen bei Queues Overflow |
| Neighbour Table | ARP/ND Tabellen-Größen bei Eintrags-Drops |
| Route Table | Route Cache Sizing |
| Netns / Sysctl | Per-Namespace Äquivalente wo anwendbar |
Wie die Feedback-Schleife funktioniert
| Schritt | Detail |
|---|
| Observe | eBPF Probes zählen Drops, Overflows, Druck-Events |
| Decide | Wenn ein Schwellwert wiederholt getroffen wird, ist der Parameter ein Bottleneck |
| Adjust | Erhöhen Sie die Limit inkrementell (nie unbegrenzt) |
| Re-observe | Bestätigen Sie das Symptom geklärt |
| Back Off | Wenn ein Admin den Wert manuell gesetzt hat, lassen Sie es allein |
Diese “Beobachte, Stoße, Überprüfe” Schleife ist warum es kontinuierlich laufen kann ohne zu oszillieren.
Seine Auswirkung überprüfen
# Was hat bpftune geändert?
sudo bpftune -s
# Bestätigen Sie einen Sysctl, den es angepasst hat
sysctl net.ipv4.tcp_rmem net.core.somaxconn
# Korrelieren Sie mit dem Symptom, das es behoben hat
ss -s # Socket/Queue Stats
netstat -s | grep -i drop # Drops, die Tuning auslösten
Wann es zu verwenden ist
| Szenario | Passung |
|---|
| Variable/unbekannte Workloads | Stark – passt sich an, wenn sich die Last ändert |
| Cloud Instanzen verschiedener Größen | Stark – keine Per-Instanz Tuning |
| Hoch getuned, feste Workload | Schwach – Ihre manuellen Werte sind wahrscheinlich besser |
| Strikte Change Control | Verwenden Sie -S Dry-run zuerst oder überspringen |
bpftune vs Manual/Profile Tuning
| Aspekt | bpftune | TuneD | Manueller Sysctl |
|---|
| Modell | Continuous, Feedback-getrieben | Statische Profile | One-time Werte |
| Passt sich an Load an | Ja | Nein | Nein |
| Config erforderlich | Keine | Wählen Sie ein Profil | Volle Expertise |
| Respektiert manuelle Einstellungen | Ja (zieht sich zurück) | Überschreibt | N/A |
Ergänzt TuneD (breite statische Profile) und direkte Tools wie cpupower; bpftune zielt auf Netzwerk/Kernel Limits spezifisch ab.
Ressourcen
