VPS lent ou lag ? Trouve la cause en 10 minutes

Si ton VPS est lent, commence par déterminer ce qui est lent exactement, puis passe en revue quatre points : le CPU (charge, un cœur à 100 % ou steal time), la mémoire (pleine, swap ou l'OOM-killer), le disque (iowait) et le réseau (ping et perte de paquets). Avec top, free, iostat et mtr, tu sais en dix minutes lequel des quatre freine.

Installe les outils à l'avance, comme ça tu les as sous la main quand ça coince :

sudo apt install htop sysstat mtr-tiny

Si tu veux des graphiques sur une période plus longue, Netdata te montre seconde par seconde ce que fait ton VPS. Pour un coup d'œil rapide, htop suffit aussi, comme dans consulter l'utilisation de ton VPS.

VPS lent ? Détermine d'abord ce qui est lent exactement

« Lent » peut vouloir dire trois choses très différentes, et chacune pointe dans une autre direction :

• Du lag en jeu : les joueurs sont ramenés à une position précédente, des blocs cassés réapparaissent, les véhicules saccadent. En général, le serveur n'arrive pas à tenir ses ticks (CPU), ou la connexion perd des paquets (réseau).
• Une session SSH lente : les lettres s'affichent avec du retard. Cela pointe vers le réseau, ou vers un VPS tellement chargé que même ton shell doit attendre.
• Un site web lent : souvent la base de données ou le disque, parfois la mémoire.

Fais aussi attention au schéma. Est-ce lent tout le temps, seulement le soir quand tout le monde est en ligne, ou toujours vers la même heure ? Une heure fixe pointe souvent vers une tâche planifiée, comme ton propre script de sauvegarde ou une tâche cron. Et est-ce qu'un seul joueur se plaint, ou tout le monde ? Si c'est un seul joueur, ça vient généralement de sa propre connexion.

CPU : charge, un cœur à 100 % et steal time

Commence par deux chiffres :

nproc
uptime

nproc donne ton nombre de vCores, uptime la charge moyenne (load average) sur 1, 5 et 15 minutes. Si la charge reste longtemps au-dessus du nombre de vCores, du travail fait la queue. Linux y compte aussi les processus qui attendent le disque, alors regarde ensuite dans top ce qui se passe. Dans top, appuie sur 1 pour voir chaque vCore séparément. Tu vois alors généralement l'un de ces trois schémas :

• Tous les cœurs saturés, avec des valeurs élevées pour us et sy : tu manques de puissance de calcul, ou un processus s'emballe. Regarde dans htop quel processus est en tête.
• Un cœur à 100 %, les autres au calme : le problème classique des serveurs de jeu. Le thread principal de Minecraft, FiveM ou Valheim est à son plafond. Plus de vCores n'aident pas dans ce cas, un cœur plus rapide si. Pour comprendre pourquoi, lis Qu'est-ce qu'un vCore ? et Ryzen ou EPYC pour ton serveur de jeu ?
• Un st élevé : le steal time, le temps pendant lequel l'hyperviseur a fait attendre ton vCore parce que le cœur physique travaillait ailleurs. Quelques pour cent de temps en temps, c'est normal avec des vCores partagés. Si st reste nettement élevé pendant longtemps alors que ton serveur est lent, garde la sortie de vmstat 1 30 et joins-la à un ticket ; notre support te donne un coup de main.

Mémoire : pleine, swap ou l'OOM-killer

free -h

Regarde la colonne available, pas free. Linux utilise la mémoire inutilisée comme cache (buff/cache) et la rend dès qu'un programme en a besoin, donc une valeur free basse est normale. Si available est presque à zéro, ta mémoire est vraiment pleine. Deux signes le confirment :

• Le swap : dans vmstat 1, les colonnes si et so restent au-dessus de zéro. Ton VPS fait passer de la mémoire vers le disque et inversement, et ça se ressent partout.
• L'OOM-killer : le noyau arrête un processus quand la mémoire est épuisée. Ton serveur de jeu semble alors planter sans message d'erreur. Vérifie-le avec sudo dmesg -T | grep -i -E 'out of memory|killed process'.

Une erreur fréquente avec les serveurs Java : régler -Xmx sur toute la mémoire du VPS. Java utilise plus que le heap, et le système d'exploitation a aussi besoin de place, alors laisse au moins 1 Go libre. Si tu fais tourner Minecraft avec des mods sur moins de 8 Go, plus de mémoire est tout simplement la solution ici.

Disque : iowait et tâches planifiées

Dans top, wa indique le temps pendant lequel le CPU attend que le disque ait fini. S'il est souvent élevé, regarde disque par disque :

iostat -x 1

Surveille r_await et w_await : le temps moyen en millisecondes que prend une requête de lecture ou d'écriture, attente dans la file comprise. Sur du NVMe, ces valeurs doivent rester basses ; si elles grimpent fortement, un processus monopolise le disque. La colonne %util ne dit pas grand-chose sur du NVMe : d'après le manuel d'iostat, elle ne reflète pas la limite des périphériques qui traitent les requêtes en parallèle. Pour voir quel processus utilise le disque, lance sudo iotop (paquet iotop).

Les coupables habituels sont ton propre script de sauvegarde ou une tâche cron qui compresse tout un dossier de monde, un fichier de log qui grossit sans limite et une requête de base de données sans index. Vérifie aussi avec df -h que le disque n'est pas plein : un disque plein provoque des erreurs bizarres et des blocages, bien avant que tu comprennes pourquoi.

Réseau : ping, mtr et perte de paquets

Mesure depuis ton propre ordinateur vers le VPS :

ping -c 20 ton-ip
mtr -rwc 100 ton-ip

Sous Windows, utilise ping -n 20 ton-ip ; pour mtr, il y a WinMTR. mtr envoie 100 cycles d'une seconde et affiche pour chaque saut intermédiaire la perte et la latence. Lis-le ainsi : une perte sur un saut intermédiaire qui ne se prolonge pas jusqu'à la dernière ligne vient généralement d'un routeur qui donne une faible priorité aux pings, et elle est sans gravité. Une perte qui se prolonge jusqu'à ton VPS inclus est réelle. Si un seul joueur se plaint, mesure aussi depuis le VPS vers son adresse IP.

Si tous les joueurs subissent des saccades en même temps, regarde d'abord sur status.mc-node.net s'il se passe quelque chose avec les nœuds. Tous les VPS sont à Hengelo ; pour savoir comment la distance jusqu'à tes joueurs détermine le ping, lis Localisation du serveur et ping.

Spécifique aux serveurs de jeu : TPS, MSPT et hitches

Un serveur de jeu mesure sa propre santé, et ces chiffres sont souvent plus parlants que top. Un serveur Minecraft veut atteindre 20 ticks par seconde, donc 50 ms maximum par tick (MSPT). Si le MSPT grimpe alors qu'un cœur est à 100 %, c'est le CPU. Si le TPS et le MSPT sont bons mais que tout le monde lag, c'est plutôt le réseau. Par jeu :

• Résoudre le lag d'un serveur FiveM, pour les hitch warnings dans la console et les scripts lourds

Quand une offre plus grande aide (et quand elle n'aide pas)

Une offre plus grande ne résout que le goulot d'étranglement que tu as trouvé :

Au sein de ta gamme, tu passes à une offre plus grande depuis l'espace client, et tu paies la différence pour le reste de ta période. Si ton goulot d'étranglement est la vitesse par cœur, le VPS Premium avec Ryzen 9 est l'étape logique : un AMD Ryzen 9 9950X* avec DDR5, jusqu'à 5,7 GHz contre jusqu'à 4,0 GHz pour l'EPYC 7443P du VPS KVM. Si c'est le steal time, tourne-toi vers un VDS avec cœurs dédiés. Changer de gamme ne se fait pas en un clic : prévois un nouveau VPS et une migration. Tu hésites sur la gamme qui te convient ? Lis Quel VPS choisir ?

* ou AMD Ryzen 9 7950X3D, selon le nœud.

Questions fréquentes

Pourquoi mon VPS est-il lent ?

Généralement à cause de l'un de ces quatre goulots d'étranglement : le CPU (un cœur à 100 % ou du steal time), la mémoire (pleine ou en swap), le disque (beaucoup d'iowait à cause d'un processus ou d'un disque plein) ou le réseau (perte de paquets). Avec top, free -h, iostat -x 1 et mtr, tu vois en dix minutes lequel c'est. Un serveur de jeu qui lag a souvent un goulot d'étranglement CPU sur le thread principal.

Qu'est-ce que le steal time, et est-ce grave ?

Le steal time (st dans top) est le temps pendant lequel ton vCore voulait calculer, mais où l'hyperviseur a donné le cœur physique à un autre VPS. Quelques pour cent de temps en temps, c'est normal avec des vCores partagés. S'il reste élevé longtemps alors que ton serveur est lent, joins la sortie de vmstat 1 30 à un ticket, ou choisis un VDS avec cœurs dédiés.

Est-ce que plus de RAM aide contre le lag ?

Seulement si la mémoire est vraiment pleine : available dans free -h est presque à zéro, ton VPS swappe ou l'OOM-killer arrête des processus. Le lag causé par un thread principal bloqué sur un seul cœur ne se règle pas avec plus de RAM ; dans ce cas, c'est un cœur plus rapide qui aide, ou moins de plugins et scripts lourds.

Comment savoir s'il y a une panne ?

Regarde sur status.mc-node.net ; tu y trouves le statut en direct des nœuds. Si rien n'y est signalé et que seul ton serveur rame, cherche la cause avec top, free, iostat et mtr. Joins la sortie de mtr depuis ton propre ordinateur quand tu ouvres un ticket.

À lire aussi

• Localisation du serveur et ping : pourquoi les Pays-Bas sont un carrefour réseau majeur
• Qu'est-ce qu'un vCore ? Comment comparer équitablement les processeurs de VPS