Dimensionnez l'application que vous exécutez réellement.

Avant de mesurer

Utilisez une machine de test Linux que vous contrôlez, avec votre application et des données représentatives. Les commandes ci-dessous inspectent les ressources ; elles ne règlent pas le noyau et ne suppriment pas de fichiers. Vous avez besoin de procps et de GNU coreutils, ainsi que de la permission d'inspecter le répertoire d'application choisi. Remplacez /srv/my-app par son chemin réel. Si l'application n'est encore en cours d'exécution nulle part, utilisez son environnement de développement ou de préproduction pour établir une estimation initiale, puis révisez cette estimation sur le système prévu.

Notez ce qui partage le VPS : système d'exploitation, proxy, API, base de données, workers et supervision. Enregistrez si les builds d'assets s'y exécutent, si les sauvegardes sont compressées localement et si une tâche planifiée peut chevaucher un déploiement. Un processus d'application au repos peut coexister avec un processus de release coûteux.

Lisez la mémoire disponible et identifiez les processus

free -m
ps -eo pid,comm,rss --sort=-rss | head -n 12

free -m rapporte des mébioctets. Concentrez-vous sur available, l'estimation de la mémoire qui pourrait soutenir un nouveau travail sans swap ; free seul exclut la mémoire récupérable utile. Le cache n'est donc pas, à lui seul, une raison d'acheter plus de RAM. Voir les définitions des champs de free.

Illustrative selected fields — not an OffVPS measurement
Mem total: 2048 MiB
Mem free:   180 MiB
Mem available: 800 MiB

Illustrative ps rows
  PID COMMAND     RSS
 2100 postgres 393216
 2140 node     184320
  920 caddy     32768

Les valeurs RSS des processus ci-dessus correspondent approximativement à 384, 180 et 32 MiB. Elles aident à localiser l'utilisation de la mémoire, mais additionner chaque valeur RSS ne donne pas un total exact de la machine : les pages partagées peuvent être comptées plusieurs fois et certains coûts du noyau sont hors du chiffre du processus. Évitez d'afficher les arguments de commande ou les environnements lors de la collecte d'un rapport, car ils peuvent contenir des secrets. Le manuel ps explique ses champs et son comportement d'instantané.

Transformez les observations en feuille de calcul

Les allocations suivantes illustrent une petite API avec une base de données locale et un worker. Ce sont des valeurs de planification inventées, pas des benchmarks ni des exigences minimales pour un framework particulier. Remplacez-les par vos mesures et notez quelles allocations peuvent culminer en même temps.

Cette feuille de calcul dépasse déjà un budget de 1,024 MiB. Un environnement de test de 2,048 MiB laisserait 676 MiB face à ces allocations, mais le résultat utile est de savoir si un travail représentatif réel tient pendant que l'application reste réactive. Si l'allocation de déploiement domine, construire les artefacts ailleurs peut être un meilleur changement que d'agrandir le serveur permanent. Conservez les hypothèses à côté du total.

Surveillez le CPU et le swap pendant le travail utile

vmstat 1 10

Exécutez ceci pendant un lot de requêtes représentatif, une tâche et une release. Ignorez la première ligne lors de l'interprétation d'un intervalle récent : elle résume l'activité depuis le démarrage. Les lignes suivantes décrivent les intervalles d'échantillonnage. Un travail exécutable persistant dans r, un faible temps d'inactivité dans id et des requêtes lentes justifient ensemble l'examen de la pression CPU. Une activité répétée de si/so montre du swapping ; un swap alloué seul ne prouve pas une pression actuelle. wa et st nécessitent du contexte plutôt qu'une mise à niveau CPU automatique. Ces champs sont définis dans vmstat.

Enregistrez aussi le temps de réponse au niveau de l'application. Une API externe ou une requête de base de données lente peut faire attendre les requêtes alors que le CPU reste majoritairement inactif. Répétez la même charge de travail après un changement, afin de savoir quel changement a aidé. Les tests de charge ne doivent cibler que des systèmes que vous contrôlez, avec un débit et une condition d'arrêt qui évitent de perturber les autres utilisateurs.

Budgétez séparément la croissance du disque et le transfert

df -h /srv/my-app
df -i /srv/my-app
du -sh /srv/my-app

df décrit le système de fichiers contenant le chemin, y compris l'espace partagé avec d'autres répertoires ; df -i vérifie l'utilisation des inodes lorsque c'est pris en charge. Un grand nombre de petits fichiers peut épuiser les inodes avant la capacité en octets. du estime l'arborescence choisie, sous réserve des permissions d'accès. Ce sont des questions différentes, donc leurs totaux ne doivent pas nécessairement correspondre. Voir df et du.

Listez la base de données actuelle, les téléversements, les journaux, les artefacts d'application et tout espace de préparation de sauvegarde local. Ajoutez l'espace nécessaire pour une release à côté de la release précédente, puis estimez la croissance sur le prochain intervalle de révision. Par exemple, 100 MiB de nouveaux téléversements chaque jour ajoutent environ 3,000 MiB sur 30 jours avant les réplicas ou les sauvegardes. Étiquetez les GB décimaux et les GiB binaires de manière cohérente lors de la comparaison du résultat avec un catalogue.

Pour le transfert, une réponse illustrative de 20 kB envoyée 50,000 fois représente environ 1 GB de charge utile de réponse. Ajoutez les téléversements, les fichiers statiques, la surcharge de protocole et le trafic de sauvegarde. Cette arithmétique estime le volume, pas le débit ni les utilisateurs simultanés. Confirmez comment le service compte le trafic et gère tout excès.

Choisissez l'action suivante et vérifiez-la

• Mémoire disponible faible pendant les pics normaux : inspectez les principaux consommateurs et testez un budget mémoire plus élevé.
• Requêtes lentes avec pression CPU soutenue : profilez le chemin occupé, puis comparez les changements CPU en utilisant la même charge de travail.
• Utilisation croissante du disque : identifiez le répertoire responsable et la politique de rétention avant de supprimer quoi que ce soit.
• Les ressources semblent confortables mais l'application est lente : examinez les dépendances, les requêtes et le chemin de la requête.

Enregistrez la feuille de calcul avec la description de la charge de travail, l'heure d'échantillonnage, les unités et la prochaine date de révision. Revérifiez après une release importante, une croissance des données ou l'ajout d'un worker. Choisissez une configuration à partir de ces observations ; aucun nom de forfait ne garantit la capacité de requêtes. Poursuivez avec la lecture des avertissements mémoire et disque ou le premier scénario de ressource API.