infra / linux-bash
sysctl et tuning noyau avancé
Explication
Ce que vous allez apprendre
- Comprendre que
sysctlexpose des milliers de paramètres noyau modifiables à chaud - Distinguer un changement temporaire (
sysctl -w) d'un changement permanent (/etc/sysctl.d/) - Appliquer un fichier de configuration entier avec
sysctl --system - Identifier les paramètres les plus souvent responsables de blocages applicatifs en production
- Toujours vérifier après coup qu'une valeur a bien été appliquée
Dans quel contexte ?
Un collègue installe Elasticsearch sur un nouveau serveur et le service refuse de démarrer avec une erreur cryptique sur "max virtual memory areas". Le vrai problème n'est pas Elasticsearch : c'est un paramètre noyau à régler avant que le service ne puisse même démarrer.
D'abord, ce que sysctl permet réellement
Le noyau Linux expose des milliers de paramètres de fonctionnement — mémoire, réseau, limites système — que l'on peut consulter et modifier sans recompiler ni redémarrer. sysctl kernel.pid_max lit un paramètre précis, et ces mêmes valeurs sont en réalité de simples fichiers dans /proc/sys que tu peux aussi lire directement avec cat.
Une fois cette interface comprise, voyons pourquoi elle compte concrètement
Ces paramètres ne sont pas des détails obscurs réservés aux experts noyau : fs.file-max trop bas provoque l'erreur "Too many open files" sous forte charge sur un serveur web, et vm.max_map_count trop bas empêche carrément Elasticsearch de démarrer. Savoir identifier le bon paramètre transforme une erreur mystérieuse en un problème résolu en une seule commande.
| Paramètre | Trop bas provoque | Contexte typique |
|---|---|---|
fs.file-max | "Too many open files" | Serveur web ou base de données sous forte charge |
vm.max_map_count | Refus de démarrage | Elasticsearch, certaines JVM |
fs.inotify.max_user_watches | Plantages d'outils de dev | webpack, VS Code sur un gros projet |
net.core.somaxconn | Connexions refusées | Forte concurrence réseau |
Il reste une distinction essentielle : temporaire contre permanent
sudo sysctl -w vm.swappiness=10 change la valeur immédiatement, mais cette modification est perdue au prochain redémarrage — pratique pour tester sans risque. Pour la rendre permanente, il faut l'écrire dans un fichier comme /etc/sysctl.d/99-tuning.conf, appliqué automatiquement au démarrage.
Voici comment appliquer un fichier de configuration sysctl
Après avoir écrit le fichier, sudo sysctl --system applique tous les fichiers de /etc/sysctl.d/ d'un coup, ou sudo sysctl -p /etc/sysctl.d/99-tuning.conf pour un fichier précis uniquement. C'est cette étape qu'on oublie facilement après avoir édité le fichier à la main.
Maintenant, un réflexe de vérification à prendre systématiquement
Une faute de frappe dans un fichier .conf (comme vm.swapiness au lieu de vm.swappiness) échoue souvent silencieusement à l'application, sans avertissement bruyant. Toujours vérifier après coup avec sysctl <clé> que la valeur attendue est bien active, plutôt que de supposer que le fichier a été pris en compte.
Réflexe à adopter
Après avoir écrit un fichier dans /etc/sysctl.d/, vérifie toujours avec sysctl <clé> que la valeur attendue est bien active. Une faute de frappe dans le nom du paramètre échoue souvent sans avertissement bruyant.
Le piège à connaître
Certains paramètres, comme kernel.osrelease, sont en lecture seule : tenter de les modifier échoue avec une erreur "Read-only", ce qui peut surprendre si on ne sait pas que tous les paramètres sysctl ne sont pas modifiables. Maintenant que tu sais régler le noyau en profondeur, la dernière leçon du cours explore des mécanismes bash réservés aux scripts d'infrastructure les plus avancés.
Commandes & code
sysctl et tuning noyau avancé
# --- sysctl : lit/modifie des paramètres noyau à chaud, sans reboot ---
sysctl -a | wc -l # nombre total de paramètres exposés (souvent 1000+)
sysctl -a | grep vm\\. # tous les paramètres de la catégorie "vm" (mémoire virtuelle)
sysctl kernel.pid_max # lecture d'un paramètre précis
sudo sysctl -w kernel.pid_max=4194304 # écriture temporaire (perdue au reboot)
# Équivalent lecture/écriture directement via /proc (sysctl est une surcouche de /proc/sys)
cat /proc/sys/kernel/pid_max
echo 4194304 | sudo tee /proc/sys/kernel/pid_max
# --- Rendre un changement permanent ---
sudo tee /etc/sysctl.d/99-tuning.conf <<'EOF'
# Limites système
kernel.pid_max = 4194304
fs.file-max = 2097152
fs.inotify.max_user_watches = 524288
# Réseau (voir aussi la leçon QoS/performance du cours Réseaux pour le détail)
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.core.somaxconn = 4096
# Mémoire virtuelle
vm.swappiness = 10
vm.max_map_count = 262144
vm.dirty_ratio = 10
EOF
sudo sysctl --system # applique TOUS les fichiers /etc/sysctl.d/*.conf d'un coup
sudo sysctl -p /etc/sysctl.d/99-tuning.conf # applique un fichier précis uniquement
# --- Cas d'usage concrets par paramètre ---
# fs.file-max : trop bas -> "Too many open files" sous forte charge (serveurs web/BDD)
cat /proc/sys/fs/file-nr # utilisés / réservés / max actuels
# vm.max_map_count : trop bas -> Elasticsearch/certaines JVM refusent de démarrer
sysctl vm.max_map_count
sudo sysctl -w vm.max_map_count=262144
# fs.inotify.max_user_watches : trop bas -> outils de dev (webpack, VS Code) plantent sur gros projets
sysctl fs.inotify.max_user_watches
cat /proc/sys/fs/inotify/max_user_instances
# net.core.somaxconn : trop bas -> connexions refusées sous forte concurrence (backlog TCP saturé)
sysctl net.core.somaxconn
# kernel.shmmax / kernel.shmall : mémoire partagée max, historique pour PostgreSQL en config manuelle
sysctl kernel.shmmax
# --- Vérifier qu'un paramètre a bien été appliqué après un redémarrage ---
sysctl kernel.pid_max
grep -r "pid_max" /etc/sysctl.d/ /etc/sysctl.conf 2>/dev/null
# --- Paramètres en lecture seule (informatifs, non modifiables) ---
sysctl kernel.osrelease
sysctl -w kernel.osrelease=x 2>&1 # échoue : "Read-only" pour les paramètres immuablesRésumé
sysctl -wchange à chaud (perdu au reboot),/etc/sysctl.d/*.conf+sysctl --systemrend le changement permanent.fs.file-max,vm.max_map_count,fs.inotify.max_user_watchessont les trois causes de blocage applicatif les plus fréquentes en prod.- Toujours vérifier après coup (
sysctl <clé>) : une faute de frappe dans un fichier.conféchoue silencieusement à l'application suivante.
Exercices pratiques
Mission : Elasticsearch refuse de démarrer
Objectif : Corriger un paramètre noyau bloquant, le rendre permanent, et détecter une faute de frappe silencieuse.
Contexte
Un collègue installe Elasticsearch sur un nouveau serveur et le service refuse de démarrer avec une erreur cryptique sur "max virtual memory areas". Tu dois identifier le vrai paramètre noyau en cause et corriger la situation durablement.