« Le serveur rame, doublons la RAM » est le réflexe le plus coûteux de l'hébergement. Parfois il est juste. Souvent, la machine attend le disque, ou le CPU est à fond, et la nouvelle mémoire ne sert à rien pendant que la facture double.
Alors avant de parler de qui a besoin de 64 GB, voyons ce qui vous manque réellement. Si vous voulez juste des chiffres de mémoire typiques par usage, notre guide précédent Combien de RAM pour un VPS les donne, formule pour les modèles de langage comprise. Cet article parle de diagnostic : RAM, disque ou CPU.
Trois commandes, deux minutes
Lancez-les sur le serveur lent pendant qu'il est lent, pas à quatre heures du matin quand il ne se passe rien :
free -m
vmstat 1 10
cat /proc/pressure/cpu /proc/pressure/memory /proc/pressure/io
Voici comment les lire sans manuel.
free -m. Ignorez la colonne free : Linux remplit exprès la mémoire disponible avec du cache disque. Regardez available. Si elle n'affiche que quelques centaines de mégaoctets sur une machine de 2 GB et que le used du swap ne cesse de grimper, la mémoire est juste.
vmstat 1 10. Quatre colonnes racontent l'essentiel :
| Colonne | Ce qu'elle mesure | Pointe vers |
|---|---|---|
si / so | pages lues et écrites dans le swap par seconde | RAM |
wa | % du temps où le CPU attend le disque | disque |
us + sy | % du temps où le CPU travaille | CPU |
st | % du temps où l'hyperviseur a donné votre CPU à quelqu'un d'autre | CPU (vCPU partagé avec d'autres) |
Quelques valeurs non nulles de si/so de temps en temps, c'est normal. Le vrai signal, c'est un swap régulier, seconde après seconde.
/proc/pressure/*. Le plus honnête des trois. Chaque fichier indique la part du temps où des tâches étaient bloquées en attente de cette ressource. some avg60=25.00 sur memory signifie que pendant la dernière minute, quelque chose attendait de la mémoire un quart du temps. Le fichier aux chiffres les plus élevés désigne votre goulot d'étranglement.
Si c'est le disque
wa élevé, forte pression io, peu de swap. La cause habituelle : une base de données ou une application très bavarde en logs qui lit plus que ce qui tient en cache.
Le rebondissement : plus de RAM peut régler ça, parce que Linux mettra davantage de disque en cache. Si votre base pèse 6 GB et que sa partie chaude fait 3 GB, passer de 2 à 8 GB de mémoire peut faire disparaître le problème de disque. Mais si la base fait 300 GB et que chaque requête touche une partie différente, aucune quantité raisonnable de RAM ne la mettra en cache. La solution passe alors par de meilleurs index, des requêtes plus petites ou une autre organisation des données. Toutes les offres ici sont sur NVMe, donc le disque lui-même est rarement la partie lente. Le schéma d'accès, si.
Si c'est le CPU
us+sy élevés, pression cpu, pas de swap, peu d'attente disque. Compression, builds, encodage vidéo, traitement d'images, calcul cryptographique. Plus de mémoire n'y changera rien.
Surveillez aussi st. Sur un VPS, un vCPU est une part du temps d'un cœur physique, pas le cœur entier : le chiffre de l'offre est un plafond pour les pics, et une pleine charge prolongée peut être bridée pour rester équitable envers tout le monde sur la machine. Si votre tâche a besoin de tous les cœurs à 100 % pendant des heures, c'est une question de charge de travail, et nous préférons vous le dire maintenant qu'après l'achat d'une offre plus grosse.
Si c'est vraiment la RAM
Swap régulier, pression mémoire en hausse, l'OOM killer dans dmesg. La question devient alors : combien.
2 GB suffisent, souvent pendant des années, pour : un bot ou quelques-uns, une petite API, un VPN, un site statique derrière Nginx, quelques scrapers en cron, un agent de supervision. Micro vous donne 2 vCPU, 2 GB et 25 GB pour 5 $ par mois en NAT, ou 10 $ avec sa propre IPv4.
4 à 8 GB, c'est le milieu confortable : une application web avec sa base, un petit index de recherche, de l'automatisation de navigateur headless, deux ou trois agents côte à côte.
32 à 64 GB, c'est pour les données qui doivent vivre en mémoire :
- une base dont le jeu de travail pèse des dizaines de gigaoctets, pour que le cache garde vraiment les données chaudes ;
- un gros cache ou une file en mémoire qui ne peut pas déborder sur le disque sans tout ralentir ;
- un index vectoriel pour la recherche sur des millions de fragments (de vrais chiffres dans RAG auto-hébergé à grande échelle) ;
- l'inférence CPU d'un modèle de langage de taille moyenne, dont les poids doivent tenir en RAM ;
- la consolidation : dix services qui vivaient auparavant sur dix petits serveurs.
C'est à ça que sert Pro-64 : 12 vCPU, 64 GB de RAM, 600 GB de NVMe et une IPv4 dédiée pour 70 $ par mois. Les paliers intermédiaires sont Pro-32 à 40 $ et Pro-48 à 55 $ ; au-dessus, Pro-80 à 90 $. La disponibilité des emplacements pour les offres Pro s'affiche à la commande.
Là où une grosse machine ne convient pas
Trois cas où 64 GB est la mauvaise réponse, même si vous pouvez vous l'offrir.
Le travail sur GPU. Aucune de ces offres n'a de GPU. Si votre modèle en a besoin pour l'entraînement ou une inférence rapide, une machine CPU avec beaucoup de RAM le fera tourner, lentement, et vous paierez pour votre patience.
Les tâches à pleine charge CPU prolongée. Comme dit plus haut : les vCPU sont une capacité de pointe. Douze d'entre eux à 100 % jour et nuit, ce n'est pas ce pour quoi un VPS est conçu.
Et le « au cas où ». Si les trois commandes ne montrent aucune pression mémoire, les 60 GB en plus servent de cache à des fichiers que vous ne lisez pas. Commencez plus petit. Passer à une offre plus grande du même type de réseau ajoute vCPU, RAM et disque sur place, avec un redémarrage, comme l'explique Changer d'offre. Redescendre sur place est impossible, donc acheter trop gros a un vrai coût : pour réduire, vous migrez vers un nouveau serveur, et déménager un VPS sans interruption est une corvée dont vous vous passeriez bien.
Si vous comparez des offres de plusieurs hébergeurs, lire les caractéristiques d'un VPS explique ce que promettent vraiment les chiffres de vCPU, de disque et de port.
Commentaires
Pas encore de commentaires. Soyez le premier.