Réglage du noyau dans l'hébergement Linux : aperçu des paramètres Sysctl

Réglage du noyau dans l'hébergement Linux apporte des gains de performance mesurables, car j'ajuste de manière ciblée les paramètres sysctl pour le réseau, la mémoire, le processeur et la sécurité. Je charge les profils sans redémarrer et j'adapte les valeurs aux charges de travail, à la concordance et au comportement des E/S, afin que le système puisse fonctionner correctement. Serveur réagit rapidement sous charge et fonctionne de manière fiable.

Points centraux

• sysctl contrôle le comportement du noyau au moment de l'exécution
• Réseau optimiser les processus : Backlogs, Sockets, TCP
• Mémoire de l'élagage : Swapping, Dirty Pages
• CPU réglage fin : ordonnanceur, PIDs
• Sécurité durcir sans overhead

Qu'est-ce que sysctl dans l'hébergement Linux ?

Avec sysctl je lis et modifie les paramètres du noyau au moment de l'exécution, sans compiler le noyau. Les valeurs se trouvent sous forme de fichiers dans le répertoire /proc/sys, par exemple net/ipv4/tcp_max_syn_backlog, et contrôlent le réseau, la mémoire et la sécurité. Pour les charges de travail d'hébergement avec de nombreuses connexions, le réglage direct réduit les pics de latence et les délais d'attente. Je modifie temporairement avec sysctl -w et j'écris des profils permanents dans /etc/sysctl.d/*.conf. Ensuite, je charge tout avec sysctl -system et je vérifie dmesg ainsi que les journaux afin de détecter rapidement les configurations erronées.

Comment utiliser sysctl en toute sécurité

Avant toute modification, je m'assure Profils et je documente les valeurs réelles avec sysctl -a afin de pouvoir revenir en arrière à tout moment. Je teste d'abord les nouvelles valeurs sur des VM de staging avec des charges comparables. Ensuite, j'augmente progressivement les paramètres, j'observe les métriques et j'ajuste à nouveau. J'évite ainsi les OOM-kills, les socket-drops et les retransmissions sporadiques. Pour des configurations reproductibles, je crée un fichier spécial tel que /etc/sysctl.d/99-hosting.conf et je le charge de manière contrôlée.

Tester temporairement #
sudo sysctl -w net.core.somaxconn=65535
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=4096

Définir # de façon permanente
sudo tee /etc/sysctl.d/99-hosting.conf >/dev/null <<'EOF'
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 4096
vm.swappiness = 10
vm.dirty_ratio = 20
EOF

sudo sysctl --système

Paramètres réseau portant sur les serveurs web

Pour de nombreuses connexions simultanées, j'augmente somaxconn, pour que le backlog de liste de Nginx ou Apache ne déborde pas. Avec net.ipv4.tcp_max_syn_backlog, j'augmente la file d'attente des connexions semi-ouvertes, ce qui aide lors des pics de trafic. Dans les configurations purement web, je laisse généralement net.ipv4.ip_forward désactivé, mais je l'active pour les reverse proxies ou les passerelles. Je valide les drops de backlog avec ss -s et netstat -s et je vérifie si les queues d'acceptation sont vides. Ceux qui veulent aller plus loin dans le contrôle de la congestion évaluent en plus des algorithmes comme CUBIC ou BBR ; ma remarque sur Contrôle de la congestion TCP.

# Exemple de valeurs pour les serveurs web très fréquentés
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.ip_forward = 0

Réglage de la mémoire et des VM pour les charges de travail d'hébergement

J'abaisse swappiness à 10, afin que le noyau utilise plus longtemps la RAM et swappe moins. Avec vm.dirty_ratio de 15 à 20 pour cent, je limite les pages sales pour que la charge d'écriture n'entraîne pas de longues rafales. Pour de nombreux processus, je règle vm.overcommit_memory sur 1 lorsque je connais les applications et que je comprends leurs réserves. En complément, j'observe les occurrences de cache de page et l'attente IO afin d'interpréter correctement les effets de la mise en cache. Pour un regard plus approfondi sur le comportement de la mémoire cache, je vous propose ce guide sur l'utilisation de la mémoire cache. Cache de la page.

# Profils de mémoire et de VM
vm.swappiness = 10
vm.dirty_ratio = 20
vm.overcommit_memory = 1

Raffinement du CPU et de l'ordonnanceur

Si la concourance est élevée, je lève kernel.pid_max pour que de nombreux processus de travail obtiennent des identifiants. Pour les quotas CFS, j'ajuste kernel.sched_cfs_bandwidth_slice_us afin d'éviter des tranches trop courtes pour les services en attente. Je vérifie les longueurs de file d'attente d'exécution, les changements de contexte et les temps de vol, en particulier sur les hôtes partagés. Si j'ai besoin d'une isolation CPU, je lie les services aux noyaux via taskset ou cgroups. Pour une introduction à l'optimisation du noyau en profondeur, voir ce petit article. Performances du noyau-guide.

# Paramètres du processus et de l'ordonnanceur
kernel.pid_max = 4194304
# Exemple de tranches CFS plus fines
kernel.sched_cfs_bandwidth_slice_us = 5000

Paramètres de sécurité sans perte de performance

J'active dmesg_restrict, pour empêcher les utilisateurs non privilégiés de lire les journaux du noyau. Avec kernel.kptr_restrict, je cache les adresses qui pourraient aider les pirates à exploiter les failles. Au niveau du réseau, j'active rp_filter par défaut pour empêcher l'usurpation d'adresse IP. Ces paramètres ne coûtent presque rien en termes de performances et renforcent nettement le durcissement de l'hôte. Je les charge de manière contrôlée dans le même fichier sysctl afin de rester compréhensible.

# Durcissement via sysctl
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1

Tampons réseau étendus pour un débit élevé

Pour les hôtes à fort trafic, je passe Mémoire tampon TCP pour que les connexions rapides ne soient pas bloquées dans la limite de la fenêtre. Avec net.ipv4.tcp_rmem et tcp_wmem, je définis des tailles minimales, standard et maximales. net.core.optmem_max et net.core.netdev_max_backlog aident à absorber proprement les courtes rafales. J'observe les retransmissions, l'évolution du cwnd et les niveaux de remplissage des tampons avant d'augmenter davantage les valeurs. Ces étapes augmentent le débit et réduisent sensiblement les fluctuations de latence sur les liens 10G modernes.

# tampons réseau étendus
net.core.optmem_max = 81920
net.core.netdev_max_backlog = 3000
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

Pratique : De la ligne de base au bénéfice mesurable

Je commence chaque tuning par une Ligne de base et je documente les chiffres clés tels que la latence P95, le débit et le taux d'erreur. Ensuite, je modifie quelques paramètres, je charge le profil et je mesure à nouveau avec ab, wrk ou sysbench. Si la latence baisse, j'enregistre la modification ; si elle augmente, je reviens en arrière. Je construis ainsi un profil d'hébergement qui correspond à mon application. Enfin, je vérifie encore une fois sous la charge de production avant de laisser les valeurs permanentes.

# Sauvegarder l'état actuel
sysctl -a > /root/sysctl-baseline.txt

# Visualiser les paramètres réseau
sysctl -a | grep -E 'net\.core|net\\N ipv4'.

# Recharger les profils
sysctl --system

Tableau comparatif : profil standard vs. profil d'hébergement

La suivante Tableau montre des valeurs de départ adaptées à la pratique, que j'utilise souvent. Les valeurs dépendent de la charge de travail, du réseau et du matériel. Je commence par là, je vérifie les métriques et j'ajuste progressivement. En cas de problème, je reviens aux valeurs par défaut et j'augmente à nouveau par petites étapes. Cela me permet de limiter les risques et d'obtenir des résultats cohérents.

Paramètres	Standard	Profil d'hébergement	Avantages
net.core.somaxconn	128	65535	Plus de connexions acceptées
net.ipv4.tcp_max_syn_backlog	1024	4096	Moins de drops sur les pics
vm.swappiness	60	10	Moins de swapping en charge
kernel.pid_max	32768	4194304	Plus de processus/travailleurs possibles
vm.dirty_ratio	30	20	Une écriture plus régulière

Éviter les erreurs fréquentes et assurer le suivi

Je ne mets pas en jeu Valeurs extrêmes, Ils peuvent entraîner des pertes de temps, des OOM-kills ou des pertes de paquets. Je teste les changements par étapes, à chaque fois avec une métrique claire et une courte phase d'observation. Les indicateurs critiques sont la longueur de la file d'attente d'acceptation, les retransmissions TCP, la latence P95, l'attente IO et le swap in/out. Pour la surveillance, j'utilise des agents et des tableaux de bord légers afin d'identifier rapidement les tendances. Après les mises à jour du noyau, je vérifie si les profils sysctl sont toujours valides et je les recharge si nécessaire.

Persistance, ordre et distributions

Pour que les profils restent reproductibles, je respecte l'ordre de chargement dans /etc/sysctl.d : Les fichiers sont traités de manière lexicographique. J'attribue délibérément des préfixes comme 60-... ou 99-... pour m'assurer que mon profil d'hébergement remplace d'autres paramètres par défaut. Les différences entre les distributions (Debian/Ubuntu vs RHEL/Alma) ne concernent généralement que les chemins et les valeurs par défaut ; sysctl -system charge toujours /etc/sysctl.conf, /etc/sysctl.d/*.conf et, le cas échéant, les fichiers des vendeurs. Après des mises à jour importantes du système, je vérifie avec sysctl -system -o (dry-run selon la version) ou je compare la configuration effective chargée avec mon modèle pour éviter les surprises.

# Exemple : assurer un ordre propre
sudo ls -1 /etc/sysctl.d
10-vendor.conf
50-defaults.conf
99-hosting.conf # écrase tout ce qui précède

# diffère les valeurs effectivement chargées
sysctl -a > /root/sysctl-after.txt
diff -u /root/sysctl-baseline.txt /root/sysctl-after.txt | less

Cycle de vie TCP et gestion des ports

Sous une forte charge, de nombreuses connexions éphémères se forment. Je place ip_local_port_range pour que les connexions sortantes (par exemple celles des proxies) ne soient pas bloquées dans la limite du port éphémère. tcp_fin_timeout contrôle combien de temps les sockets restent dans FIN-WAIT-2. Avec des Keepalive-je supprime plus rapidement les sessions mortes sans couper les connexions de manière agressive. TIME_WAIT est normal et protège contre les paquets tardifs ; je ne le réduis pas aveuglément. tcp_tw_reuse aide principalement sur les hôtes clients, il reste généralement éteint sur les serveurs purs. Je laisse les timestamps et SACK activés, car ils améliorent les performances et la robustesse.

# Plage de ports et cycle de vie TCP
net.ipv4.ip_local_port_range = 10240 65535
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 5
# Attention à tcp_tw_reuse : utile uniquement pour la charge client sortante
# net.ipv4.tcp_tw_reuse = 1

Maintenir la stabilité d'IPv6 et des tables voisines

De nombreux hôtes portent aujourd'hui un trafic à double pile. J'optimise les tables ARP/ND afin d'éviter les messages „neighbour table overflow“, notamment sur les proxies ou les nœuds avec de nombreux pairs. Le site gc_thresh-Je définis les seuils en fonction de la matrice de connexion. Pour les serveurs, je laisse les options ICMPv6 et Router-Advert restrictives, afin qu'aucun itinéraire non souhaité n'entre en ligne de compte. Pour IPv4, je veille en outre à la collecte des déchets ARP, afin que les entrées vieillissent à temps, mais ne disparaissent pas trop tôt.

# Tables voisines : seuils plus généreux
net.ipv4.neigh.default.gc_thresh1 = 1024
net.ipv4.neigh.default.gc_thresh2 = 4096
net.ipv4.neigh.default.gc_thresh3 = 8192

net.ipv6.neigh.default.gc_thresh1 = 1024
net.ipv6.neigh.default.gc_thresh2 = 4096
net.ipv6.neigh.default.gc_thresh3 = 8192

# ARP/ND-aging conservateur
net.ipv4.neigh.default.gc_stale_time = 60

Penser ensemble les descripteurs de fichiers et les backlogs

Les goulots d'étranglement les plus fréquents sont Descripteurs de fichiers. Si les applications tiennent des milliers de sockets, fs.file-max (pour tout le système) et ulimit/nofile (par service) vont ensemble. somaxconn augmente certes la file d'attente de listes, mais n'aide que si le serveur web lui-même est autorisé à ouvrir plus de FD et si le taux d'acceptation est suffisamment élevé. Je m'assure que les limites du système et des services sont synchronisées, sinon des bottlenecks artificiels apparaissent malgré les „gros“ backlogs du noyau.

# Autoriser plus de FDs dans tout le système
fs.file-max = 2097152

# Côté service (exemple d'unité systemd)
# [Service]
# LimitNOFILE=1048576

Amortir les charges de travail UDP/QUIC

Utiliser DNS, syslog, télémétrie et QUIC (HTTP/3) UDP. Ici, je mets à l'échelle les tampons de socket globaux et les limites de mémoire spécifiques à l'UDP. Pour les charges UDP importantes et en cours (comme les passerelles de télémétrie), cela évite les drops dans le chemin de réception. J'observe les compteurs d'erreurs avec ss -u -a et netstat -su et j'ajuste graduellement les maxima. Pour QUIC, net.core.rmem_max/wmem_max est également pertinent, car les piles de l'espace utilisateur se heurtent souvent à ces limites via setsockopt.

# Tampons et limites UDP
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456
net.ipv4.udp_mem = 98304 131072 262144
net.ipv4.udp_rmem_min = 8192
net.ipv4.udp_wmem_min = 8192

Préciser le Dirty-Writeback : Octets au lieu de pourcentages

Sur les systèmes disposant de beaucoup de RAM, les pourcentages peuvent entraîner des flushs importants et brusques. C'est pourquoi je préfère utiliser vm.dirty_background_bytes et vm.dirty_bytes, pour définir des limites supérieures absolues. Cela permet de stabiliser le taux d'écriture et de lisser les latences, en particulier pour les disques durs ou les charges de travail mixtes. En outre, je considère vm.min_free_kbytes modérée, afin que le noyau conserve suffisamment de mémoire libre pour les allocations en rafale.

# Exemple : limites de dirty absolues (environ 1G de fond, 4G de dur)
vm.dirty_background_bytes = 1073741824
vm.dirty_bytes = 4294967296
vm.min_free_kbytes = 65536

Répartition de la charge RPS/RFS et IRQ réseau

Lorsque le taux de PPS est élevé, un seul cœur de CPU peut être bloqué sur le NIC-IRQ. J'utilise Receive Packet Steering (RPS) et, le cas échéant, Receive Flow Steering (RFS) pour répartir le traitement des paquets sur plusieurs cœurs. Je définis globalement net.core.rps_sock_flow_entries, L'affectation proprement dite s'effectue par file d'attente via Sysfs. Cela réduit les points chauds du CPU, améliore la localité du cache et réduit les pics de latence. En combinaison avec net.core.netdev_max_backlog, on obtient un pipeline plus robuste.

# Entrées de flux globales pour RPS
net.core.rps_sock_flow_entries = 32768

# Remarque : tuning per-queue via /sys/class/net//queues/rx-*/rps_cpus
# et rps_flow_cnt, selon la carte réseau et le nombre de files d'attente.

Conteneurs, espaces de noms et VMs

Dans les conteneurs, beaucoup net.*-valeurs namespaced et peuvent s'appliquer par espace de nommage réseau. Je documente donc si je personnalise le réseau hôte ou le réseau pod/conteneur. Les orchestrateurs n'autorisent souvent qu'une liste sûre de sysctls ; des valeurs comme kernel.pid_max restent côté hôte. Sur les VM, je vérifie quelles cartes réseau virtuelles et quels offloads sont actifs (virtio, ENA), car les offloads et les MTU ont un impact important sur les besoins en tampon et le développement du cwnd. Les hôtes bare metal chargés de NUMA profitent de la désactivation de vm.zone_reclaim_mode et une disposition d'affinité CPU/IRQ délibérée.

# Éviter les effets secondaires du NUMA
vm.zone_reclaim_mode = 0

Conntrack et Stateful Firewalls en vue

Si l'hôte fonctionne en tant que NAT/pare-feu ou héberge de nombreux conteneurs avec egress-NAT, je redimensionne les nf_conntrack-table. Les tables de hachage trop petites génèrent des drops et des latences élevées lors des scans de tables. Je mesure la charge de travail avec nstat et regarde „expected“ vs „in use“. Pour les serveurs web purs sans NAT, conntrack n'est souvent pas critique ou même désactivé ; sur les passerelles, il doit impérativement faire partie du package de réglage.

# Taille de Conntrack (seulement si utilisé activement !)
net.netfilter.nf_conntrack_max = 1048576

Robustesse contre les attaques et les anomalies

Aider sous le trafic de bots et les scans tcp_syncookies et des options ICMP/redirection conservatrices. Les syncookies sauvent le handshake en cas de débordement des files SYN, sans ralentir excessivement le trafic légitime. Je désactive les redirections et les sources sur les serveurs qui ne doivent pas être routés. Ces renforcements sont légers et complètent judicieusement les mécanismes de protection mentionnés ci-dessus.

# Défense contre les floods SYN et comportement de routage conservateur
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

Approfondir la pratique de la mesure : Ce que je contrôle régulièrement

Pour obtenir des résultats reproductibles, je mesure de manière cohérente avant et après les modifications. Côté réseau, j'utilise ss -s, ss -ti, nstat et netstat -s pour voir les longueurs de file d'attente, les retransmissions et les statistiques de sac. Du côté de la mémoire/des E/S, vmstat, iostat et pidstat aident à classer les dirty flushes, les changements de contexte et les temps d'attente du CPU. Sous tests de charge, je regarde en plus

• File d'attente d'acceptation (LISTEN) et file d'attente SYN : Dropped vs. Overflows
• Pacing/Throughput par connexion et développement cwnd
• Latences P95/99 en comparaison A/B, au lieu de seulement la moyenne
• Taux de swap in/out et taux d'utilisation du cache de pages
• Répartition de la charge IRQ et longueurs de file d'attente d'exécution par CPU

# Chèques de statut rapides
ss -s
netstat -s | egrep 'listen|SYN|retran|dropped'.
vmstat 1 10
pidstat -w -u -r 1 5

Exemple : profil d'hébergement consolidé

Pour commencer, je combine les valeurs de base et les valeurs avancées dans un fichier. Ensuite, j'augmente par petites étapes, à chaque fois avec des points de mesure clairs. Les valeurs suivantes constituent un point de départ conservateur mais performant pour les serveurs web et les proxies très fréquentés.

sudo tee /etc/sysctl.d/99-hosting.conf >/dev/null <<'EOF
# Les bases du réseau
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 4096
net.core.netdev_max_backlog = 3000
net.core.optmem_max = 81920

# TCP buffer et ports
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.ip_local_port_range = 10240 65535
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 5

# UDP/QUIC
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456
net.ipv4.udp_mem = 98304 131072 262144
net.ipv4.udp_rmem_min = 8192
net.ipv4.udp_wmem_min = 8192

# Tables voisines
net.ipv4.neigh.default.gc_thresh1 = 1024
net.ipv4.neigh.default.gc_thresh2 = 4096
net.ipv4.neigh.default.gc_thresh3 = 8192
net.ipv6.neigh.default.gc_thresh1 = 1024
net.ipv6.neigh.default.gc_thresh2 = 4096
net.ipv6.neigh.default.gc_thresh3 = 8192
net.ipv4.neigh.default.gc_stale_time = 60

# Sécurité
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

# Mémoire/VM
vm.swappiness = 10
vm.dirty_ratio = 20
vm.dirty_background_bytes = 1073741824
vm.dirty_bytes = 4294967296
vm.min_free_kbytes = 65536
vm.overcommit_memory = 1
vm.zone_reclaim_mode = 0

# CPU/processus
kernel.pid_max = 4194304
kernel.sched_cfs_bandwidth_slice_us = 5000

# RPS
net.core.rps_sock_flow_entries = 32768

# FDs
fs.file-max = 2097152
EOF

sudo sysctl --système

Résumé : Le tuning comme processus répétitif

Cibler Réglage du noyau avec sysctl produit des effets clairs dans l'hébergement : temps de réponse plus courts, débit plus élevé et services constants. Je commence par les bases du réseau comme somaxconn et tcp_max_syn_backlog, puis je m'occupe de la mémoire avec swappiness et dirty_ratio. Ensuite, j'optimise les PID et les ordonnanceurs et je durcis l'hôte avec dmesg_restrict, kptr_restrict et rp_filter. Je mesure chaque changement, je le documente et je garde un œil sur les métriques. C'est ainsi qu'est créé, étape par étape, un profil qui sert efficacement mes charges de travail et qui garde des réserves pour les pics de trafic.