Optimiser les performances d'un VPS Linux : mémoire, disque et réseau

Pourquoi optimiser les performances d'un VPS Linux

Un VPS (Virtual Private Server, ou serveur privé virtuel) fraichement livré par votre hébergeur fonctionne avec les réglages par défaut de la distribution : noyau configuré pour un usage généraliste, mises à jour manuelles, buffers réseau calibrés pour un poste de travail. La couche de virtualisation (KVM, Xen) partage les ressources physiques du processeur (CPU), de la RAM et de l'espace disque entre plusieurs serveurs virtuels hébergés sur la même machine hôte. Contrairement à un serveur dédié où l'administrateur dispose de toutes les ressources bare-metal, un VPS doit tirer le meilleur parti de ses vCPU, de sa mémoire et de sa bande passante alloués.

Ces valeurs par défaut conviennent à un usage basique, mais un serveur virtuel qui héberge un site web sous Nginx ou Apache, une base de données MySQL ou PostgreSQL, un serveur de jeu ou des conteneurs Docker gagne en réactivité et en stabilité avec quelques ajustements ciblés du noyau, du réseau et du stockage. Que votre VPS Linux serve des scripts PHP, des applications Python ou un serveur FiveM, les optimisations décrites ici s'appliquent à tous les cas d'usage courants.

Ce guide rassemble les optimisations les plus efficaces sur un VPS sous Ubuntu (22.04 LTS, 24.04 LTS) ou Debian 12. Chaque réglage est expliqué avec sa commande, sa valeur recommandée et la raison technique derrière le changement. L'accès root (ou un utilisateur admin avec sudo) est requis pour tous les réglages. Si vous hésitez encore sur le système d'exploitation, consultez notre guide quelle distribution Linux choisir pour un VPS.

Maintenir le système à jour

Les mises à jour du système corrigent des failles de sécurité, des bugs du noyau et des régressions de performance dans les paquets installés. Sur un VPS en production, un paquet obsolète peut exposer un service à une vulnérabilité connue ou dégrader les performances d'un composant critique (OpenSSL, glibc, pilotes réseau virtio). Connectez-vous en SSH en tant que root ou avec un compte admin disposant des droits sudo.

Mise à jour manuelle

La commande classique met à jour la liste des paquets puis installe les nouvelles versions disponibles :

sudo apt update && sudo apt upgrade -y

Ajoutez sudo apt dist-upgrade -y pour les mises à jour qui nécessitent l'installation ou la suppression de paquets supplémentaires (changement de dépendances du noyau, par exemple). Un redémarrage du VPS est nécessaire après une mise à jour du noyau pour que le nouveau kernel soit pris en compte : sudo reboot.

Mises à jour automatiques avec unattended-upgrades

Pour ne pas dépendre d'une connexion SSH quotidienne, installez unattended-upgrades qui applique automatiquement les correctifs de sécurité :

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

La commande dpkg-reconfigure active le téléchargement et l'installation automatique des mises à jour de sécurité. Vérifiez la configuration dans /etc/apt/apt.conf.d/50unattended-upgrades. Pour planifier d'autres tâches de maintenance sur votre VPS, consultez notre guide planifier des tâches automatiques avec cron et systemd timers.

Optimiser la gestion de la mémoire : vm.swappiness

Le paramètre vm.swappiness contrôle la propension du noyau Linux à déplacer les pages mémoire inactives de la RAM vers l'espace swap sur disque. La valeur par défaut est 60 (sur une échelle de 0 à 200 depuis le noyau 5.8, ou de 0 à 100 sur les noyaux antérieurs). Sur un VPS, un swappiness élevé provoque des écritures inutiles vers le disque, ce qui augmente la latence des applications et sollicite le processeur pour gérer les entrées/sorties supplémentaires.

Pour un serveur web (Nginx, Apache avec PHP-FPM) ou un serveur d'applications, une valeur de 10 réduit le recours au swap tout en le conservant comme filet de sécurité en cas de pic mémoire. Pour un serveur de cache (Redis, Memcached) ou une base de données en mémoire, une valeur de 1 minimise encore davantage le swap. Si votre VPS déclenche le OOM killer (arrêt brutal de processus faute de mémoire), notre guide comprendre le OOM killer Linux explique le mécanisme.

# Appliquer immédiatement
sudo sysctl vm.swappiness=10

# Rendre permanent (persiste après redémarrage)
echo 'vm.swappiness = 10' | sudo tee /etc/sysctl.d/99-vps-tuning.conf
sudo sysctl --system

Vérifiez la valeur en cours avec cat /proc/sys/vm/swappiness. Si votre VPS manque de RAM et swap régulièrement, la solution passe d'abord par l'ajout de swap ou l'augmentation de la RAM. Consultez notre guide configurer le swap sur un VPS Linux pour dimensionner correctement votre fichier swap.

Accélérer les écritures disque : vm.dirty_ratio

Le noyau Linux accumule les données modifiées (pages dirty) en RAM avant de les écrire sur le disque. Deux paramètres contrôlent ce comportement :

• vm.dirty_background_ratio : pourcentage de la mémoire totale à partir duquel le noyau déclenche l'écriture en arrière-plan. Valeur par défaut : 10 %.
• vm.dirty_ratio : pourcentage maximal de mémoire occupée par des pages dirty avant que les processus soient forcés d'attendre la fin des écritures. Valeur par défaut : 20 %.

Sur un VPS avec un stockage SSD NVMe rapide, réduire ces valeurs limite le risque de perte de données en cas de crash et lisse les pics d'I/O. Des valeurs de 5 % (background) et 15 % (ratio) constituent un bon compromis entre performances d'écriture et sécurité des données :

sudo sysctl vm.dirty_background_ratio=5
sudo sysctl vm.dirty_ratio=15

Pour rendre ces valeurs permanentes, ajoutez-les au fichier de configuration sysctl créé précédemment :

cat <<EOF | sudo tee -a /etc/sysctl.d/99-vps-tuning.conf
vm.dirty_background_ratio = 5
vm.dirty_ratio = 15
EOF
sudo sysctl --system

Surveillez l'activité disque après modification avec iostat pour vérifier que les écritures sont bien lissées. Notre guide diagnostiquer les I/O disque d'un VPS Linux avec iostat détaille les colonnes à surveiller.

Activer le TRIM périodique pour les SSD

Le TRIM informe le contrôleur SSD des blocs qui ne sont plus utilisés, ce qui lui permet de regrouper les données et de maintenir les performances d'écriture dans le temps. Sans TRIM, le SSD doit effacer des blocs occupés par des données supprimées avant d'écrire, ce qui dégrade progressivement les performances et réduit l'espace disque effectivement disponible.

Sur Ubuntu 18.04+ et Debian 10+, le timer systemd fstrim.timer est généralement préinstallé. Il exécute fstrim une fois par semaine sur tous les systèmes de fichiers montés qui le supportent. Vérifiez son état et activez-le si nécessaire :

# Vérifier le statut du timer
systemctl status fstrim.timer

# Activer et démarrer le timer
sudo systemctl enable --now fstrim.timer

# Vérifier la prochaine exécution
systemctl list-timers fstrim.timer

Le TRIM périodique (hebdomadaire) est préférable au TRIM continu (option discard dans /etc/fstab). Le TRIM continu provoque une pause à chaque suppression de fichier pour envoyer la commande TRIM au contrôleur SSD, ce qui dégrade les performances lors de suppressions massives. Pour surveiller l'espace disque restant sur votre VPS et anticiper les saturations, consultez notre guide surveiller l'espace disque d'un VPS Linux.

Optimiser les services applicatifs : Nginx, Apache et bases de données

Les réglages sysctl améliorent le comportement du noyau, mais les services applicatifs qui tournent sur votre VPS ont leurs propres paramètres de performance. Un serveur web mal configuré ou une base de données avec les réglages par défaut peut gaspiller du CPU et de la mémoire, quel que soit le tuning du noyau.

Nginx : workers et connexions

Pour un VPS qui héberge un site web ou sert de reverse proxy, Nginx est le choix le plus courant grâce à son faible usage mémoire. Deux paramètres sont à ajuster dans /etc/nginx/nginx.conf :

# Adapter le nombre de workers au nombre de vCPU
worker_processes auto;

events {
    # Connexions simultanées par worker
    worker_connections 1024;
}

La directive worker_processes auto crée un worker par vCPU disponible. Pour un VPS avec 2 vCPU, cela signifie 2 workers. Pensez à redémarrer Nginx après modification : sudo systemctl reload nginx. Notre guide configurer Nginx en reverse proxy détaille la configuration complète.

Apache : MPM event

Si votre pile applicative utilise Apache (souvent installé avec un panel d'administration comme Plesk), passez au MPM event plutôt que prefork. Le MPM event consomme moins de mémoire par connexion et gère mieux les connexions keep-alive :

sudo a2dismod mpm_prefork
sudo a2enmod mpm_event
sudo systemctl restart apache2

Ajustez ensuite les limites de threads dans /etc/apache2/mods-available/mpm_event.conf en fonction de la RAM disponible. Chaque thread Apache consomme entre 5 et 15 Mo de mémoire selon les modules chargés.

PHP-FPM : pool et processus

Pour les scripts PHP (WordPress, Laravel, applications sur mesure), PHP-FPM en mode dynamic évite de bloquer des processus inutilement. Configurez le pool dans /etc/php/8.3/fpm/pool.d/www.conf :

pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

Le paramètre pm.max_children dépend de la RAM disponible : chaque processus PHP consomme entre 20 et 80 Mo selon l'application. Sur un VPS avec 4 Go de RAM qui héberge aussi une base de données MySQL, 10 à 15 children est un bon point de départ. Les applications Python (Django, Flask) ont des mécanismes équivalents avec Gunicorn ou uWSGI.

MySQL : InnoDB buffer pool

Si votre VPS héberge une base de données MySQL ou MariaDB, le paramètre le plus impactant est innodb_buffer_pool_size. Il contrôle la quantité de RAM allouée au cache des données et des index des bases de données. La valeur par défaut (128 Mo) est trop basse pour un serveur en production :

# /etc/mysql/mysql.conf.d/tuning.cnf
[mysqld]
innodb_buffer_pool_size = 1G

Allouez 50 à 70 % de la RAM disponible au buffer pool si MySQL est le service principal du VPS. Redémarrer le service est nécessaire : sudo systemctl restart mysql. Pour l'installation initiale, consultez notre guide installer MySQL sur un VPS Linux.

Optimiser le réseau avec TCP BBR

BBR (Bottleneck Bandwidth and Round-trip propagation time) est un algorithme de contrôle de congestion TCP développé par Google. Contrairement à l'algorithme par défaut CUBIC, qui ajuste le débit en réaction aux pertes de paquets, BBR estime la bande passante disponible et le temps de propagation pour maintenir un débit plus stable avec moins de latence. BBR est intégré au noyau Linux depuis la version 4.9. Sur un VPS dont la bande passante est partagée entre plusieurs serveurs virtuels, BBR exploite mieux la capacité réseau allouée par l'hébergeur.

Pour activer BBR, configurez le scheduler de file d'attente fq (Fair Queue) et l'algorithme de congestion :

# Vérifier les algorithmes disponibles
sysctl net.ipv4.tcp_available_congestion_control

# Appliquer BBR
sudo sysctl net.core.default_qdisc=fq
sudo sysctl net.ipv4.tcp_congestion_control=bbr

# Vérifier
sysctl net.ipv4.tcp_congestion_control

Pour rendre le changement permanent :

cat <<EOF | sudo tee -a /etc/sysctl.d/99-vps-tuning.conf
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
EOF
sudo sysctl --system

Le scheduler fq est indispensable pour que BBR fonctionne correctement : il fournit le contrôle de débit par flux (pacing) dont BBR a besoin pour lisser les envois de paquets. Sans fq, BBR perd sa capacité de pacing et se comporte de manière moins prévisible. Pour mesurer le gain réel de bande passante après activation de BBR, utilisez iperf3 entre deux serveurs.

Augmenter les buffers réseau

Les buffers par défaut du noyau sont dimensionnés pour des connexions modestes. Sur un VPS qui sert des fichiers volumineux, héberge un serveur de jeu ou gère de nombreuses connexions simultanées vers son adresse IP publique, augmenter les buffers TCP améliore le débit et réduit les retransmissions :

cat <<EOF | sudo tee -a /etc/sysctl.d/99-vps-tuning.conf
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
EOF
sudo sysctl --system

Ces valeurs portent les buffers TCP maximum à 16 Mo (réception et émission). Le noyau ajuste dynamiquement la taille réelle par connexion entre les valeurs minimum, par défaut et maximum spécifiées. Cela profite aussi bien au trafic HTTP qu'aux protocoles comme DNS, FTP ou SMTP qui transitent par le même stack réseau. Pour diagnostiquer les problèmes de résolution DNS sur votre VPS, consultez notre guide diagnostiquer la résolution DNS sous Linux.

Firewall : configurer le suivi des connexions sans brider le réseau

Le firewall (iptables, nftables ou UFW) filtre le trafic entrant et sortant de votre VPS en fonction de l'adresse IP source, du port et du protocole. Le module conntrack du noyau suit chaque connexion active dans une table. Sur un VPS qui reçoit beaucoup de connexions (serveur web, serveur de jeu, reverse proxy), la table conntrack par défaut peut saturer et provoquer des pertes de paquets.

Vérifiez la taille actuelle de la table et sa limite :

# Connexions suivies en ce moment
cat /proc/sys/net/netfilter/nf_conntrack_count

# Limite maximale
cat /proc/sys/net/netfilter/nf_conntrack_max

Si le compteur s'approche de la limite (65 536 par défaut), augmentez-la :

cat <<EOF | sudo tee -a /etc/sysctl.d/99-vps-tuning.conf
net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_tcp_timeout_established = 3600
EOF
sudo sysctl --system

Réduire le timeout des connexions établies (de 432 000 secondes par défaut à 3 600, soit une heure) libère les entrées conntrack plus rapidement. Si vous avez des connexions longue durée (sessions SSH d'administration, réplication de bases de données), conservez un timeout suffisant pour ne pas les interrompre. Pour configurer les règles de firewall elles-mêmes, consultez notre guide configurer nftables sur un VPS Linux.

Planifier les sauvegardes sans dégrader les performances

Les sauvegardes (backup) sont indispensables pour tout VPS en production, mais un script de sauvegarde lancé en heure de pointe peut saturer les I/O disque et le CPU du serveur. Pour limiter l'impact sur les performances :

• Planifiez les sauvegardes en heures creuses : un script lancé par cron ou un timer systemd entre 3 h et 5 h du matin évite de concurrencer les services en production.
• Limitez la bande passante des sauvegardes distantes : rsync --bwlimit=10000 bride le transfert à 10 Mo/s pour ne pas saturer la bande passante du VPS pendant la copie vers le serveur de backup.
• Réduisez la priorité I/O : ionice -c3 rsync ... place le processus en classe idle. Les I/O de sauvegarde ne s'exécutent que quand le disque est libre.
• Sauvegardez les bases de données séparément : un mysqldump planifié est moins impactant qu'une copie brute des fichiers de données MySQL. Notre guide sauvegarder MySQL avec mysqldump et cron détaille la méthode.

Pour configurer des sauvegardes complètes vers un serveur distant avec rsync, consultez notre guide sauvegarder un VPS avec rsync.

Tableau récapitulatif des paramètres sysctl

Ces valeurs sont un point de départ. Adaptez-les à votre charge de travail et surveillez l'impact avec htop et btop pour la mémoire et le CPU, et iostat pour les I/O disque. Le nombre de vCPU et la génération du processeur influencent aussi les performances brutes de votre VPS : notre article vCPU d'un VPS : pourquoi tous les hébergeurs ne se valent pas détaille ce qui différencie les offres.

VPS, serveur dédié ou mutualisé : impact sur l'optimisation

Le niveau d'optimisation possible dépend du type d'hébergement choisi :

Sur un VPS KVM (comme ceux d'ElypseCloud), tous les réglages de ce guide sont applicables car chaque serveur virtuel dispose de son propre noyau. Les VPS en conteneur (OpenVZ, LXC) partagent le noyau de l'hôte : les paramètres sysctl ne sont pas toujours modifiables. En hébergement mutualisé, aucun accès root n'est disponible et les optimisations se limitent aux fichiers de configuration applicatifs (.htaccess pour Apache, php.ini pour PHP). Pour comparer VPS et serveur dédié, consultez notre guide serveur dédié bare-metal vs VPS.

Fichier de configuration complet

Voici le contenu complet du fichier /etc/sysctl.d/99-vps-tuning.conf qui regroupe tous les paramètres sysctl de ce guide :

# /etc/sysctl.d/99-vps-tuning.conf
# Optimisation VPS Linux - memoire, disque, reseau, firewall

# Memoire
vm.swappiness = 10
vm.dirty_background_ratio = 5
vm.dirty_ratio = 15

# Reseau - TCP BBR
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

# Reseau - buffers
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# Firewall - conntrack
net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_tcp_timeout_established = 3600

Appliquez-le avec sudo sysctl --system. Le fichier est chargé automatiquement à chaque démarrage du VPS. Il n'est pas nécessaire de redémarrer le serveur virtuel pour appliquer les changements sysctl.

Surveiller les performances après optimisation

Appliquer des réglages sans les mesurer revient à régler un moteur à l'aveugle. Mettez en place un monitoring régulier pour vérifier l'impact réel de chaque modification :

• Mémoire et swap : free -h pour vérifier l'utilisation de la RAM et du swap. Si le swap est régulièrement sollicité malgré un swappiness bas, votre VPS manque de RAM.
• CPU et processus : htop ou btop pour visualiser la charge par processeur, la mémoire par processus et le steal time (temps CPU volé par l'hyperviseur de virtualisation). Un steal time supérieur à 10 % indique que le serveur hôte est surchargé.
• Charge système : uptime affiche le load average sur 1, 5 et 15 minutes. Notre guide interpréter la charge système avec uptime explique comment lire ces valeurs en fonction du nombre de vCPU.
• I/O disque : iostat -x 1 pour surveiller les latences d'écriture et le pourcentage d'utilisation du disque. Consultez notre guide diagnostiquer les I/O disque avec iostat.
• Réseau : ss -s pour le nombre de connexions TCP actives, iperf3 entre deux serveurs pour mesurer le débit réel et la bande passante utilisée.
• Monitoring continu : pour un suivi dans la durée avec des graphiques et des alertes, déployez Grafana et Prometheus ou configurez des alertes de monitoring qui préviennent l'admin par e-mail ou webhook quand un seuil est dépassé.

Notez les mesures avant et après chaque changement. Un paramètre qui n'améliore pas les performances mesurées sur votre charge de travail ne vaut pas la complexité ajoutée.

Conclusion

Optimiser un VPS Linux repose sur quelques réglages ciblés : réduire le swappiness pour garder les données actives en RAM, lisser les écritures disque avec des seuils dirty ajustés, activer le TRIM hebdomadaire pour préserver l'espace disque SSD, passer à TCP BBR pour exploiter la bande passante allouée, et dimensionner correctement les services applicatifs (Nginx ou Apache, PHP-FPM, bases de données MySQL). Le tuning du firewall conntrack et la planification des sauvegardes en heures creuses complètent le tableau. Tous les paramètres noyau se regroupent dans un seul fichier /etc/sysctl.d/99-vps-tuning.conf et s'appliquent en une commande.

Pour compléter la sécurisation de votre serveur après ces optimisations, consultez notre guide sécuriser SSH sur un VPS Linux.