Linux sysctl est l’interface principale pour lire et modifier les paramètres du noyau à l’exécution sans redémarrer. Que vous gériez un serveur web à fort trafic, un hôte de base de données ou une charge de travail conteneurisée, le réglage du noyau avec sysctl peut améliorer considérablement le débit, réduire la latence et prévenir l’épuisement des ressources. Dans ce guide, vous apprendrez quels paramètres sont les plus importants, comment les appliquer en toute sécurité et comment les rendre persistants après les redémarrages via /etc/sysctl.conf et les fichiers de configuration drop-in sous /etc/sysctl.d/.

Prérequis

  • Un système Linux avec le noyau 4.x ou ultérieur (Ubuntu 20.04+, Debian 11+, RHEL 8+ ou équivalent)
  • Accès sudo ou root
  • Familiarité de base avec la ligne de commande et un éditeur de texte (nano, vim ou vi)
  • Une compréhension de la charge de travail du serveur (web, base de données, usage général)

Comprendre l’interface sysctl

La commande sysctl est une fine couche au-dessus du pseudo-système de fichiers /proc/sys/. Chaque paramètre réglable correspond à un fichier sous ce chemin. Par exemple, le paramètre net.ipv4.tcp_fin_timeout correspond à /proc/sys/net/ipv4/tcp_fin_timeout. Vous pouvez le lire directement avec cat ou via sysctl :

# Les deux commandes retournent le même résultat
sysctl net.ipv4.tcp_fin_timeout
cat /proc/sys/net/ipv4/tcp_fin_timeout

Écrire dans ces fichiers est équivalent à exécuter sysctl -w, mais les modifications effectuées de l’une ou l’autre façon sont temporaires — elles disparaissent au redémarrage. Le flux de travail standard consiste à tester avec -w d’abord, puis à persister la configuration une fois satisfait.

Pour voir tous les réglables à la fois :

sysctl -a

Pour filtrer par espace de noms :

sysctl -a | grep net.ipv4.tcp

Paramètres de gestion de la mémoire

vm.swappiness

vm.swappiness contrôle la propension du noyau à déplacer des pages mémoire de la RAM vers l’espace swap. L’échelle va de 0 (éviter le swap autant que possible) à 200 (swap agressif). La valeur par défaut du noyau est 60.

Pour les serveurs applicatifs et les bases de données qui ont besoin que les données restent en RAM :

sudo sysctl -w vm.swappiness=10

Pour les systèmes de bureau où la réactivité prime sur la conservation des caches chauds, 60 voire plus peut être approprié. Pour les systèmes sans swap, régler cette valeur à 0 empêche toute activité de swap.

vm.dirty_ratio et vm.dirty_background_ratio

Ces paramètres contrôlent la quantité de mémoire sale (non écrite) tolérée par le système avant de forcer un vidage sur disque.

  • vm.dirty_background_ratio (valeur par défaut 10) — pourcentage de la mémoire totale à partir duquel la réécriture en arrière-plan commence
  • vm.dirty_ratio (valeur par défaut 20) — pourcentage à partir duquel les processus sont bloqués jusqu’à l’écriture des pages sales

Pour les serveurs avec des SSD rapides ou des charges d’écriture importantes, des valeurs plus basses réduisent le risque de blocages d’écriture prolongés :

sudo sysctl -w vm.dirty_background_ratio=5
sudo sysctl -w vm.dirty_ratio=10

vm.vfs_cache_pressure

Ce paramètre contrôle l’agressivité avec laquelle le noyau récupère la mémoire utilisée pour la mise en cache des objets de répertoire et d’inode. La valeur par défaut est 100. La réduire (par exemple à 50) pousse le noyau à conserver plus longtemps les métadonnées du système de fichiers en cache, ce qui bénéficie aux charges de travail avec de nombreux petits fichiers :

sudo sysctl -w vm.vfs_cache_pressure=50

Réglage de la pile réseau avec net.core et net.ipv4

net.core.somaxconn

net.core.somaxconn définit la longueur maximale de la file d’attente d’écoute pour accepter les nouvelles connexions TCP. La valeur par défaut du noyau est 128, ce qui est bien trop faible pour tout service exposé sur le web. Nginx, Apache et Node.js bénéficient tous d’une valeur bien plus grande :

sudo sysctl -w net.core.somaxconn=65535

Votre application doit également appeler listen() avec un grand backlog. Pour Nginx, définissez listen 80 backlog=65535; dans le bloc server.

net.core.netdev_max_backlog

Ce paramètre contrôle le nombre de paquets que la carte réseau peut mettre en file d’attente avant que le noyau ne les abandonne. Sous des charges à haute bande passante, la valeur par défaut de 1000 peut provoquer des pertes de paquets :

sudo sysctl -w net.core.netdev_max_backlog=5000

Taille des tampons TCP

Le noyau utilise des tampons de réception et d’émission par socket pour contenir les données en transit. Des tampons plus grands améliorent le débit sur les liens à haute latence (réseaux longs et larges) :

# Tampon de réception : minimum, par défaut, maximum (octets)
sudo sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"

# Tampon d'émission : minimum, par défaut, maximum (octets)
sudo sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

# Maximum global pour les tampons de socket
sudo sysctl -w net.core.rmem_max=16777216
sudo sysctl -w net.core.wmem_max=16777216

TIME_WAIT et réutilisation des connexions

Les serveurs à fort trafic créent des milliers de connexions de courte durée. Sans réglage, les sockets restent en état TIME_WAIT jusqu’à deux minutes et épuisent les ports éphémères :

# Réutiliser les sockets TIME_WAIT pour les nouvelles connexions sortantes
sudo sysctl -w net.ipv4.tcp_tw_reuse=1

# Réduire la durée de TIME_WAIT (par défaut 60 secondes)
sudo sysctl -w net.ipv4.tcp_fin_timeout=30

# Élargir la plage de ports locaux pour les connexions sortantes
sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535"

Protection contre les attaques SYN flood

Activez les cookies SYN pour vous protéger des attaques SYN flood sans rejeter les connexions légitimes :

sudo sysctl -w net.ipv4.tcp_syncookies=1
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=2048

Limites des descripteurs de fichiers et des processus

Les serveurs à haute concurrence (serveurs web, brokers de messages, agents de supervision) ouvrent simultanément des milliers de descripteurs de fichiers. La limite système au niveau du noyau est contrôlée par fs.file-max :

# Afficher le maximum système actuel
sysctl fs.file-max

# Augmenter à 2 millions pour les serveurs sous forte charge
sudo sysctl -w fs.file-max=2000000

Notez que fs.file-max est un plafond au niveau du noyau. Vous devez également augmenter les limites par processus via /etc/security/limits.conf ou le paramètre LimitNOFILE de l’unité systemd pour permettre aux processus individuels d’utiliser cette nouvelle capacité.

Persister les paramètres : sysctl.conf vs fichiers drop-in

L’approche traditionnelle : /etc/sysctl.conf

Ajoutez les paramètres directement dans /etc/sysctl.conf :

# Réglage mémoire
vm.swappiness = 10
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
vm.vfs_cache_pressure = 50

# Réglage réseau
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048

# Limite des descripteurs de fichiers
fs.file-max = 2000000

Appliquer sans redémarrer :

sudo sysctl -p

L’approche moderne : fichiers drop-in /etc/sysctl.d/

Les fichiers drop-in sous /etc/sysctl.d/ sont l’approche privilégiée sur les distributions basées sur systemd. Ils permettent aux paquets, aux outils de gestion de configuration (Ansible, Puppet, Chef) et aux scripts personnalisés de gérer chacun leur propre ensemble de paramètres sans modifier un fichier partagé.

Créez un fichier dédié :

sudo nano /etc/sysctl.d/99-webserver-tuning.conf

Ajoutez vos paramètres au même format clé = valeur. Rechargez tous les fichiers drop-in et /etc/sysctl.conf avec :

sudo sysctl --system

Les fichiers sont traités dans l’ordre lexicographique. Le préfixe 99- garantit que votre fichier est chargé en dernier, écrasant les valeurs par défaut conflictuelles définies par les paquets du système.

Paramètres par défaut vs recommandés : tableau comparatif

ParamètreValeur par défautRecommandé (serveur web)Notes
vm.swappiness6010Conserver les données applicatives en RAM
vm.dirty_background_ratio105Vider les pages sales plus tôt
vm.dirty_ratio2010Réduire le risque de blocage d’écriture
vm.vfs_cache_pressure10050Conserver les métadonnées du système de fichiers en cache
net.core.somaxconn12865535Supporter une haute concurrence de connexions
net.core.netdev_max_backlog10005000Éviter les pertes de paquets sous charge
net.ipv4.tcp_fin_timeout6030Libérer les sockets plus rapidement
net.ipv4.tcp_tw_reuse01Réutiliser les sockets TIME_WAIT
net.ipv4.ip_local_port_range32768–609991024–65535Plus de ports éphémères
fs.file-max~1000002000000Supporter un grand nombre de fichiers ouverts

Scénario réel

Vous disposez d’un serveur Nginx en production gérant 5 000 connexions HTTP simultanées. Les utilisateurs voient intermittence des erreurs 502 Bad Gateway et des délais de connexion aux heures de pointe. Vous exécutez ss -s et constatez des milliers de sockets bloqués en état TIME_WAIT, et dmesg affiche TCP: request_sock_TCP: Possible SYN flooding on port 443. Le serveur dispose de 16 Go de RAM et utilise à peine le swap, pourtant free -h montre une faible utilisation des buffers/caches.

Voici la séquence de réglage que vous appliquez :

# Étape 1 : Diagnostic
ss -s
sysctl net.core.somaxconn net.ipv4.tcp_fin_timeout fs.file-max

# Étape 2 : Appliquer les correctifs à la volée
sudo sysctl -w net.core.somaxconn=65535
sudo sysctl -w net.ipv4.tcp_tw_reuse=1
sudo sysctl -w net.ipv4.tcp_fin_timeout=30
sudo sysctl -w net.ipv4.ip_local_port_range="1024 65535"
sudo sysctl -w net.ipv4.tcp_syncookies=1
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=2048
sudo sysctl -w vm.swappiness=10
sudo sysctl -w fs.file-max=2000000

# Étape 3 : Surveiller pendant 15 minutes
watch -n 5 ss -s

# Étape 4 : Si amélioré, persister les paramètres
sudo tee /etc/sysctl.d/99-webserver-tuning.conf <<'EOF'
net.core.somaxconn = 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048
vm.swappiness = 10
fs.file-max = 2000000
EOF

sudo sysctl --system

Le nombre de sockets en TIME_WAIT passe de plusieurs milliers à quelques centaines en quelques minutes, et les erreurs 502 cessent.

Pièges et Cas Particuliers

Les modifications ne sont pas héritées par les processus en cours d’exécution. Lorsque vous augmentez fs.file-max, les workers Nginx déjà en cours fonctionnent toujours sous l’ancienne limite par processus. Vous devez également mettre à jour /etc/security/limits.conf et redémarrer le service, ou définir LimitNOFILE dans le fichier d’unité systemd.

tcp_tw_reuse s’applique uniquement aux connexions sortantes. Il permet à la pile locale de réutiliser un socket TIME_WAIT comme source d’une nouvelle connexion sortante. Il n’affecte pas les connexions entrantes des clients. Ne le confondez pas avec tcp_tw_recycle, qui a été supprimé dans le noyau 4.12 et causait des échecs de connexion derrière un NAT.

net.core.somaxconn est un plafond, pas un plancher. Si votre application appelle listen() avec un backlog plus petit, le noyau utilise la valeur la plus basse. Réglez à la fois le paramètre du noyau et la configuration de l’application.

Les conteneurs héritent de l’espace de noms du noyau hôte. Les paramètres sysctl définis dans /etc/sysctl.d/ sur l’hôte s’appliquent à tous les conteneurs. Certains paramètres peuvent être définis par espace de noms réseau via docker run --sysctl ou les contextes de sécurité des pods Kubernetes, mais la plupart nécessitent un accès au niveau de l’hôte.

Tester avec des charges de travail irréalistes est dangereux. Effectuez toujours des benchmarks avec un trafic qui reflète la production. Un paramètre qui améliore le débit en laboratoire peut dégrader la latence en production si les caractéristiques de la charge de travail diffèrent.

Résolution de Problèmes

Permission refusée lors de l’écriture d’un paramètre : Certains paramètres sont en lecture seule (marqués dans /proc/sys/ en mode 444) et ne peuvent pas être modifiés à l’exécution. D’autres nécessitent une option de compilation spécifique du noyau. Consultez dmesg pour les messages d’erreur après une tentative d’écriture.

Le paramètre ne survit pas au redémarrage : Vérifiez que le fichier se trouve sous /etc/sysctl.d/ avec une extension .conf et ne contient aucune erreur de syntaxe. Exécutez sudo sysctl --system et vérifiez la sortie pour “Applying /etc/sysctl.d/99-custom.conf” afin de confirmer qu’il est bien chargé.

Erreur de paramètre introuvable (sysctl: cannot stat /proc/sys/...) : Le paramètre nécessite un module noyau non chargé. Chargez le module d’abord (par exemple modprobe nf_conntrack) et réessayez.

Valeurs inattendument basses après application des paramètres : Un autre fichier de configuration chargé ultérieurement écrase les vôtres. Vérifiez l’ordre de chargement dans la sortie de sysctl --system et renommez votre fichier avec un préfixe numérique plus élevé (par exemple 99- au lieu de 10-).

Résumé

  • sysctl lit et écrit les paramètres du noyau exposés via /proc/sys/ à l’exécution sans redémarrage
  • Utilisez sysctl -w pour les tests temporaires, puis persistez les valeurs dans /etc/sysctl.d/99-custom.conf
  • Utilisez sudo sysctl --system pour recharger tous les fichiers de configuration ; utilisez sudo sysctl -p pour recharger uniquement /etc/sysctl.conf
  • vm.swappiness=10 maintient les données applicatives en RAM sur les serveurs avec suffisamment de mémoire
  • net.core.somaxconn=65535 et net.ipv4.tcp_tw_reuse=1 sont les modifications à fort impact pour la concurrence des serveurs web
  • fs.file-max définit le plafond noyau pour les fichiers ouverts — vous devez également augmenter les limites par processus dans l’application ou l’unité systemd
  • Les fichiers drop-in sous /etc/sysctl.d/ sont préférables à l’édition directe de /etc/sysctl.conf
  • Appliquez toujours les modifications à l’exécution d’abord, surveillez sous charge, puis ne persistez que ce qui s’avère bénéfique

Articles Connexes