Optimiser un VPS Linux : swap, limites système et tuning

Optimiser un VPS Linux ne consiste pas à copier une liste de paramètres trouvée sur Internet. Une modification utile pour un serveur web très sollicité peut être inutile, voire nuisible, pour une base de données ou un petit serveur applicatif. La bonne méthode consiste à mesurer, identifier le goulot d’étranglement, ajuster un paramètre, puis mesurer de nouveau.

La stabilité doit rester prioritaire sur les micro-gains. Un serveur légèrement moins rapide mais prévisible, observable et correctement dimensionné vaut mieux qu’un système agressivement modifié dont le comportement devient difficile à expliquer. Avant tout changement, sauvegardez les fichiers concernés et prévoyez une méthode de retour arrière.

Mesurer avant d’optimiser

Commencez par déterminer quelle ressource limite réellement le VPS : CPU, mémoire vive, stockage ou réseau. Une charge élevée ne signifie pas automatiquement que le processeur manque de puissance. Elle peut aussi provenir de processus bloqués dans l’attente du disque.

top et htop permettent d’observer les processus, leur consommation CPU et leur utilisation mémoire :

top
htop

Vérifiez ensuite la mémoire disponible et l’utilisation du swap :

free -h

La colonne available est généralement plus représentative que la colonne free, car Linux utilise volontairement une partie de la RAM comme cache. Une mémoire presque entièrement utilisée n’est donc pas nécessairement un problème.

Pour étudier l’activité du stockage, utilisez iostat, fourni selon la distribution par le paquet sysstat :

iostat -xz 1

Une latence élevée, une file d’attente persistante ou un périphérique proche de la saturation peuvent révéler un goulot d’étranglement lié aux entrées et sorties. Contrôlez également l’espace disponible :

df -h

Un système de fichiers presque plein peut dégrader les performances et provoquer des erreurs applicatives. Enfin, vmstat fournit une vue synthétique du CPU, de la mémoire, du swap et des attentes d’entrées et sorties :

vmstat 1

Observez le serveur pendant une période représentative. Une mesure prise pendant trente secondes au milieu de la nuit ne décrit pas la charge d’un pic de trafic. Un outil comme Netdata facilite cette observation dans la durée. Conservez des valeurs de référence afin de comparer objectivement la situation avant et après chaque modification.

Ajouter un fichier de swap

Le swap est un espace disque que Linux peut utiliser lorsque la pression sur la mémoire augmente. Sans swap, un VPS dont la RAM est saturée risque de déclencher l’OOM killer, le mécanisme chargé de terminer des processus afin de libérer de la mémoire.

Vérifiez d’abord si un swap existe déjà :

swapon --show
free -h

Pour créer un fichier de swap de 2 Gio, utilisez fallocate :

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Si fallocate n’est pas adapté au système de fichiers utilisé, dd constitue une alternative :

sudo dd if=/dev/zero of=/swapfile bs=1M count=2048 status=progress
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Pour réactiver automatiquement ce swap au démarrage, ajoutez cette ligne à /etc/fstab :

/swapfile none swap sw 0 0

Validez ensuite la configuration :

sudo swapon --show
sudo mount -a

Le swap sur un stockage NVMe bénéficie de faibles latences par rapport à un disque mécanique, mais il reste nettement plus lent que la RAM. Il doit être considéré comme un filet de sécurité contre les pics ponctuels, pas comme un remplacement de mémoire vive. Une activité de swap continue indique souvent un manque de RAM, une fuite mémoire ou un mauvais dimensionnement.

Ajuster la swappiness

Le paramètre vm.swappiness influence la tendance du noyau à déplacer des pages mémoire vers le swap. Sa valeur par défaut est souvent 60, mais elle peut varier selon la distribution et l’environnement.

Consultez la valeur active :

sysctl vm.swappiness

Sur un serveur disposant d’assez de RAM, une valeur de 10 est un point de départ courant pour privilégier la mémoire vive tout en conservant le swap comme protection :

sudo sysctl -w vm.swappiness=10

Pour rendre ce réglage persistant, créez par exemple /etc/sysctl.d/99-vps-tuning.conf avec le contenu suivant :

vm.swappiness=10

Puis chargez la configuration :

sudo sysctl --system

Une valeur faible n’est pas universellement meilleure. Certains workloads profitent du déplacement de pages rarement utilisées afin de réserver davantage de RAM au cache disque. Surveillez vmstat, les défauts de page et les latences applicatives avant de conclure.

Relever les limites de fichiers ouverts

Chaque socket réseau, fichier journal et connexion à une base peut consommer un descripteur de fichier. Une limite trop basse produit l’erreur Too many open files, même si le serveur dispose encore de CPU et de mémoire.

Affichez la limite de la session courante :

ulimit -n

Pour définir des limites par utilisateur, utilisez /etc/security/limits.conf ou un fichier placé dans /etc/security/limits.d/ :

www-data soft nofile 65535
www-data hard nofile 65535

Les services lancés par systemd ne reprennent pas toujours les limites d’une session interactive. Pour un service comme Nginx, créez une surcharge :

sudo systemctl edit nginx

Ajoutez ensuite :

[Service]
LimitNOFILE=65535

Rechargez systemd et redémarrez le service :

sudo systemctl daemon-reload
sudo systemctl restart nginx

Vérifiez la valeur réellement appliquée :

systemctl show nginx -p LimitNOFILE

Augmenter nofile ne corrige pas une fuite de descripteurs. Si leur nombre progresse sans redescendre, recherchez d’abord un problème dans l’application ou sa gestion des connexions.

Ajuster les paramètres réseau avec prudence

Sur un serveur à fort trafic, net.core.somaxconn définit la taille maximale de la file d’attente des connexions en attente d’acceptation. Consultez sa valeur avant de la modifier :

sysctl net.core.somaxconn

Une valeur plus élevée peut aider lorsque l’application accepte correctement les connexions mais subit de brèves rafales :

net.core.somaxconn=4096

net.ipv4.tcp_fin_timeout contrôle la durée de certains états de fermeture TCP. Une réduction modérée peut être pertinente sur un serveur qui crée un grand nombre de connexions courtes :

net.ipv4.tcp_fin_timeout=30

Placez les réglages retenus dans /etc/sysctl.d/99-vps-tuning.conf, puis appliquez-les avec :

sudo sysctl --system

Ces paramètres ne compensent ni une application lente, ni un proxy mal configuré, ni une limite applicative trop basse. Vérifiez aussi la file d’écoute du service, les erreurs réseau et le nombre de connexions. Évitez les longues listes de réglages « magiques » : certains paramètres anciens sont désormais inutiles, tandis que d’autres peuvent réduire la fiabilité ou affaiblir les protections du noyau.

Nettoyer les services et paquets inutiles

Chaque service actif consomme de la mémoire, du temps CPU et parfois des entrées et sorties. Il augmente également la surface d’attaque. Listez les services démarrés :

systemctl --type=service --state=running

Examinez aussi les unités activées au démarrage :

systemctl list-unit-files --type=service --state=enabled

Si un service est réellement inutile, arrêtez-le et désactivez son démarrage automatique :

sudo systemctl disable --now nom-du-service

Ne désactivez pas un composant dont vous ignorez le rôle. Vérifiez ses dépendances, son journal et son utilité pour l’administration distante avant d’agir. Supprimez également les paquets devenus inutiles avec le gestionnaire de paquets de la distribution, après avoir contrôlé la liste proposée.

Exploiter le NVMe et réduire les écritures

Le NVMe offre déjà d’excellentes performances. Le tuning doit donc viser les écritures inutiles et la régularité des latences plutôt que des gains artificiels dans un benchmark.

L’option noatime empêche la mise à jour de la date de dernier accès à chaque lecture de fichier. Elle peut réduire les écritures, notamment sur les systèmes qui consultent beaucoup de petits fichiers. Une entrée dans /etc/fstab peut ressembler à ceci :

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / ext4 defaults,noatime 0 1

Ne recopiez jamais cet exemple tel quel. Identifiez le véritable UUID avec findmnt ou blkid, conservez le type de système de fichiers existant et sauvegardez /etc/fstab. Une erreur dans ce fichier peut empêcher le démarrage normal du VPS.

Maintenir le noyau et les paquets à jour

Les mises à jour apportent des correctifs de sécurité, mais aussi des améliorations du noyau, des pilotes, du réseau et des systèmes de fichiers. Sur Debian ou Ubuntu :

sudo apt update
sudo apt upgrade

Sur une distribution utilisant DNF :

sudo dnf upgrade

Planifiez les redémarrages requis après une mise à jour du noyau et vérifiez la compatibilité des applications critiques. Une mise à jour en production doit suivre une sauvegarde et, idéalement, une validation sur un environnement comparable.

Appliquer une méthode reproductible

Changez un seul paramètre à la fois, notez sa valeur initiale et définissez le résultat attendu. Mesurez ensuite le débit, les latences, la consommation mémoire et les erreurs pendant une période comparable. Sans cette discipline, il devient impossible de savoir quelle modification a réellement aidé.

Conservez les réglages dans des fichiers versionnés ou dans un outil de gestion de configuration. Documentez leur justification et la procédure de retour arrière. Évitez de sur-optimiser : sur un petit VPS constamment sous pression, ajouter de la RAM ou choisir une taille mieux adaptée apporte souvent davantage qu’une accumulation de réglages noyau.

Les VPS TalCloud s’inscrivent dans un environnement français avec serveurs en France, conformité RGPD, stockage NVMe, protection Anti-DDoS Netrix et support humain. Quel que soit l’hébergeur, le principe reste identique : observer la charge réelle, dimensionner correctement les ressources, puis n’ajuster que les paramètres dont l’effet peut être mesuré.