Surveiller les ressources

Votre VPS ralentit, votre site met dix secondes à répondre, ou vous voulez simplement savoir si votre offre est bien dimensionnée. Cette page donne la méthode : où regarder, quelles commandes lancer, comment lire le résultat, et à quel moment la bonne réponse n’est plus d’optimiser mais de changer de palier.

Gardez en tête ce que vous surveillez. Votre quota est celui de votre palier : 2 vCPU et 4 Go de RAM sur un VPS Start, 16 vCPU et 32 Go sur un VPS Ultra, avec un réseau à 1 Gb/s — le détail est sur la page de l’offre. Saturer, c’est dépasser votre quota, pas celui de la machine physique.

Lire les graphiques du panel

La fiche de votre service dans l’espace client sur cloudfive.fr/manager présente l’usage de la machine vu de l’extérieur (comment la retrouver). C’est le premier endroit à regarder, pour une raison simple : ces chiffres continuent d’être relevés même quand votre VPS ne répond plus.

Ce qu’ils vous apprennent, et qu’une commande lancée dans le serveur ne vous dira pas :

La forme de la courbe. Un pic à 100 % tous les jours à 3 h du matin, c’est une sauvegarde. Un plateau continu depuis mardi, c’est un processus parti en boucle.
Le moment où ça a commencé. Recoupez cette date avec vos dernières modifications : une mise à jour, un nouveau script, un plugin installé.
Le trafic réseau. Une montée brutale et soutenue peut venir de l’extérieur. La protection anti-DDoS filtre en permanence et ne demande aucune action de votre part (comment elle fonctionne), mais un trafic légitime qui explose reste à votre charge.

Les commandes utiles : htop, df, iotop, ss

Connectez-vous en SSH (guide) et déroulez les quatre familles dans cet ordre. Installez d’abord les outils qui manquent :

apt install htop iotop sysstat     # Debian, Ubuntu

Le processeur et la charge.

uptime                 # charge moyenne sur 1, 5 et 15 minutes
htop                   # vue triable par CPU (F6) ; q pour quitter
nproc                  # nombre de vCPU dont vous disposez

La charge moyenne se lit en la comparant au nombre de vCPU. Sur un VPS à 2 vCPU : une charge à 1, la machine travaille ; à 2, elle est pleine ; à 8, les processus attendent leur tour et tout devient lent. Regardez surtout la valeur à 15 minutes : la première varie trop pour conclure.

La mémoire.

free -h                # RAM utilisée, disponible, et swap

Ne vous alarmez pas d’une RAM « presque pleine » : Linux utilise la mémoire libre comme cache disque, c’est voulu. La colonne qui compte est available. Le signal d’alerte réel, c’est le swap qui se remplit et s’active en continu : la machine écrit sur le disque ce qu’elle devrait garder en mémoire, et les performances s’écroulent.

Le disque.

df -h                  # espace libre par partition
df -i                  # inodes libres : le piège des millions de petits fichiers
du -xh --max-depth=1 / | sort -h    # qui occupe la place, de haut en bas
iotop -o               # qui écrit sur le disque en ce moment

Le réseau et les ports.

ss -tulpen             # ports en écoute et processus associés
ss -tn state established | wc -l    # nombre de connexions en cours

Un service qui écoute sur un port auquel vous ne vous attendez pas mérite une vérification. La liste de référence des ports par service est dans Ports et protocoles par service.

Identifier un processus qui consomme trop

Classez les processus par consommation et relevez le coupable.
Fenêtre de terminal
```
ps -eo pid,user,pcpu,pmem,etime,cmd --sort=-pcpu | head -15
```
Remplacez --sort=-pcpu par --sort=-pmem pour refaire le classement sur la mémoire. Un processus peut être calme en CPU et avaler toute la RAM.
Regardez la colonne de durée (etime). Un processus lancé il y a trois semaines et qui tourne encore à 100 % n’est pas en train de travailler, il est bloqué.
Lisez le journal du service concerné avant de le toucher : la cause y est souvent écrite en clair.
Fenêtre de terminal
```
journalctl -u nom-du-service -n 50 --no-pager
```
Redémarrez le service plutôt que de tuer le processus. Un systemctl restart laisse le système cohérent, un kill -9 laisse parfois des fichiers verrouillés derrière lui.
Fenêtre de terminal
```
systemctl restart nom-du-service
```
Si le problème revient après chaque redémarrage, cherchez la cause et non le symptôme : une tâche planifiée qui se superpose à elle-même, une requête de base sans index, un script qui boucle sur une erreur réseau.

Un processus inconnu qui consomme tout, avec un nom aléatoire et un trafic sortant soutenu, peut signaler une machine compromise. Dans ce cas, ne vous contentez pas de le tuer : coupez l’accès réseau du service concerné, prenez une copie des journaux, et ouvrez un ticket. Un serveur compromis se réinstalle (guide) — on ne le nettoie pas.

Mettre en place des alertes

Ne comptez pas sur une alerte extérieure : status.cloudfive.xyz publie les incidents de plateforme, pas la saturation de votre machine. L’alerte sur votre propre consommation, c’est à vous de la poser. Le plus simple tient en quelques lignes.

#!/bin/sh
# Prévient quand une partition dépasse 85 % d'occupation
SEUIL=85
df -P | awk -v s="$SEUIL" 'NR>1 && int($5) > s {print $6" : "$5" utilisé"}' > /tmp/alerte.txt
[ -s /tmp/alerte.txt ] && mail -s "VPS 203.0.113.10 : disque" vous@exemple.fr < /tmp/alerte.txt

*/30 * * * * /usr/local/bin/alerte-disque.sh

Si vous voulez aller plus loin, trois approches classiques, du plus léger au plus complet :

Une sonde extérieure qui teste votre site ou votre port toutes les minutes. C’est la seule qui vous prévient quand la machine est complètement tombée — un outil installé dans le VPS ne peut pas alerter sur sa propre mort.
Un agent de métriques installé sur le serveur, qui garde l’historique et affiche des graphiques détaillés.
Un serveur de supervision séparé, si vous gérez plusieurs machines.

Quand faut-il passer à une offre supérieure

Optimiser a ses limites. Les signaux qui disent qu’il faut plus de machine, et non plus de réglages :

Signal observé pendant plusieurs jours	Ce qu’il indique
Charge moyenne durablement au-dessus du nombre de vCPU	manque de CPU
Swap utilisé en permanence, `available` au plus bas	manque de RAM
Disque au-delà de 80 % sans fichier à supprimer	manque d’espace
`iotop` toujours occupé, temps de réponse en dents de scie	contention disque
Lenteur aux heures de pointe uniquement	dimensionnement juste

Si deux de ces lignes vous concernent, le changement de palier est le bon choix : il est immédiat et sans engagement, et la procédure est dans Changer de formule. Pour arbitrer entre un palier supérieur et un autre type de machine, lisez VPS ou serveur dédié : où est la limite.

À l’inverse, si la lenteur ne vient que d’une application mal réglée, changer d’offre ne fera que repousser le problème d’un mois. Les cas les plus fréquents côté applicatif sont une base de données sans index, un cache absent, ou un serveur de jeu hébergé sur un VPS alors qu’une offre dédiée au jeu ferait mieux (comparaison).

Si ça ne marche pas

Les commandes ne sont pas installées. htop, iotop et ss ne font pas toujours partie de l’image de base. Installez-les avec le gestionnaire de paquets de votre distribution ; ss vient du paquet iproute2.

df -h annonce de l’espace libre mais les écritures échouent. Vérifiez les inodes avec df -i. Une partition peut avoir 30 Go libres et plus un seul inode disponible, à cause de millions de petits fichiers — typiquement un dossier de sessions ou de cache jamais purgé.

La charge est élevée mais aucun processus ne consomme de CPU. La machine attend le disque ou le réseau, pas le processeur. Lancez iotop -o puis vmstat 1 5 et regardez la colonne wa : si elle est haute, le goulot est le disque.

Les chiffres du panel et ceux du serveur ne concordent pas. C’est normal dans une certaine mesure : ils ne mesurent pas au même endroit ni au même pas de temps. Fiez-vous au panel pour la tendance et au serveur pour l’instant présent. Un écart énorme et durable mérite en revanche un ticket, avec vos relevés.

Vous n’arrivez même plus à vous connecter pour mesurer. C’est l’autre guide : Dépannage : mon VPS est inaccessible.