bpftune - Guide de tuning automatique du kernel avec eBPF
bpftune (par Oracle) est un daemon léger qui règle automatiquement les paramètres du kernel Linux en utilisant eBPF. Plutôt que d’exiger qu’un admin devine les valeurs sysctl, il observe le comportement réel du système via des probes eBPF — pression du buffer TCP, saturation de table de connexion, reclaim mémoire — et ajuste continuellement les paramètres pertinents au fur et à mesure que la charge change. Son principe directeur est d’être invisible : overhead quasi-zéro, aucune configuration requise, et il se retire délibérément de tout paramètre qu’un administrateur a défini manuellement.
Le tuning automatique change le comportement du kernel sur un système vivant. L’essayer sur les hôtes non-critiques et regarder les logs avant un déploiement large.
Prérequis
- Kernel Linux avec support BPF et BTF (5.15+ recommandé)
- Privilèges root (charge les programmes eBPF, écrit les sysctls)
Installation
| Platform | Commande |
|---|
| Oracle Linux / Fedora | sudo dnf install bpftune |
| Depuis la source | git clone https://github.com/oracle/bpftune && make && sudo make install |
| Service | sudo systemctl enable --now bpftune |
| Vérifier | bpftune -h |
Exécuter
| Commande | Description |
|---|
sudo bpftune | Exécuter au premier plan |
sudo bpftune -d | Exécuter en tant que daemon |
sudo systemctl start bpftune | Démarrer via systemd |
sudo bpftune -s | Montrer le résumé des tuners et l’état actuel |
journalctl -u bpftune -f | Regarder les décisions de tuning live |
Options clés
| Flag | Effet |
|---|
-d | Mode daemon |
-s | Sortie résumé/status |
-S | Supprimer (dry-run) — log ce qu’il changerait |
-L | Mode learning / comportement legacy |
-r | Rollback les changements à la sortie |
-l LEVEL | Verbosité du log |
# Voir ce qu'il règlerait sans rien changer
sudo bpftune -S -l debug
Ce qu’il règle
| Tuner | Ajuste |
|---|
| TCP buffer | tcp_rmem / tcp_wmem sous pression de throughput |
| TCP congestion | Sélection d’algorithme de congestion |
| Limites de connexion | somaxconn, tailles de backlog quand les files overflow |
| Neighbour table | Tailles de table ARP/ND quand les entrées sont dropped |
| Route table | Route cache sizing |
| Netns / sysctl | Équivalents per-namespace où applicable |
| Étape | Détail |
|---|
| Observer | Les probes eBPF comptent les drops, overflows, événements de pression |
| Décider | Si un seuil est régulièrement touché, le paramètre est un goulot |
| Ajuster | Élever la limite graduellement (jamais sans limite) |
| Re-observer | Confirmer que le symptôme a disparu |
| Back off | Si un admin a défini la valeur manuellement, la laisser seule |
Cette boucle “observe, nudge, verify” est pourquoi elle peut tourner continuellement sans osciller.
Vérifier son effet
# Qu'a bpftune changé ?
sudo bpftune -s
# Confirmer un sysctl qu'elle a signalé comme ajusté
sysctl net.ipv4.tcp_rmem net.core.somaxconn
# Corréler avec le symptôme qu'elle fixait
ss -s # stats de socket/file d'attente
netstat -s | grep -i drop # drops qui ont déclenché le tuning
Quand l’utiliser
| Scénario | Fit |
|---|
| Workloads variables/inconnus | Fort — s’adapte au fur et à mesure que la charge change |
| Instances cloud de tailles différentes | Fort — aucun tuning per-instance |
| Workload hautement tuné, fixe | Faible — vos valeurs manuelles sont probablement meilleures |
| Contrôle de changement strict | Utiliser -S dry-run en premier, ou ignorer |
bpftune vs tuning manuel/profil
| Aspect | bpftune | TuneD | sysctl manuel |
|---|
| Modèle | Continu, feedback-driven | Profils statiques | Valeurs one-time |
| S’adapte à la charge | Oui | Non | Non |
| Config requise | Aucune | Choisir un profil | Expertise complète |
| Respecte les paramètres manuels | Oui (se retire) | Écrase | N/A |
Complète TuneD (profils statiques larges) et des outils directs comme cpupower ; bpftune cible spécifiquement les limites réseau/kernel.
Ressources
