Lisez les avertissements de mémoire et de disque avant de mettre à niveau.

Capturer une petite référence avec son contexte

Utilisez un compte Linux autorisé à inspecter l’application que vous exploitez. Les commandes ici examinent l’état ; elles ne suppriment pas de fichiers et ne redimensionnent pas le stockage. Certains répertoires et journaux nécessitent un accès élevé. Remplacez /var/lib/field-api, /opt/field-api et /opt/first-api par des chemins d’application réels, et confirmez que ces chemins existent avant d’interpréter les résultats.

Notez l’heure, la version actuelle et l’activité : trafic ordinaire, un téléversement, une tâche de rapport ou une compilation de déploiement. Prenez un autre relevé pendant une activité comparable. Deux captures d’écran sans lien peuvent faire paraître une machine saine incohérente. Si des utilisateurs sont déjà touchés, capturez le premier indice utile dans le guide de défaillance applicative avant d’effectuer plusieurs changements à la fois.

Lire la mémoire disponible, puis inspecter la charge de travail

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

Dans free, la mémoire disponible estime ce qui pourrait être utilisé pour de nouvelles applications sans recourir au swap. Elle tient compte du cache récupérable, donc elle répond à une question différente de la mémoire « libre » totalement inutilisée. Voir le manuel free en amont. Linux utilise la mémoire pour le cache de fichiers ; un cache important seul ne prouve pas une fuite. La présentation de la mémoire du noyau explique pourquoi le cache et la mémoire applicative coexistent.

Relevé illustratif, et non une mesure serveur : un petit hôte dispose d’environ 1.9 Gio de mémoire utilisable, 80 Mio libres et 850 Mio disponibles. Le faible chiffre de mémoire libre seul ne justifie pas une mise à niveau. Si la mémoire disponible tombe régulièrement près de zéro pendant un rapport, que les requêtes ralentissent et que des messages pertinents d’allocation ou d’out-of-memory apparaissent, ces preuves combinées méritent une investigation.

Le ps commande liste la RSS des processus en Kio, du plus grand au plus petit. La RSS décrit la mémoire résidente, pas une comptabilité complète de la propriété exclusive ; les pages partagées peuvent apparaître dans plusieurs processus. N’additionnez pas chaque chiffre RSS et ne traitez pas le résultat comme l’usage exact de l’hôte. La référence ps en amont définit la RSS et le tri. Notez le nom du processus et si son empreinte revient vers son niveau antérieur après la fin de la charge de travail.

Le swap utilisé peut refléter une activité antérieure ; il ne prouve pas à lui seul une pression actuelle. Distinguez aussi la capacité de l’hôte des limites de service ou de conteneur. Un processus contraint peut échouer alors que l’hôte dispose encore de mémoire. Inspectez la limite configurée et l’heure de la défaillance avant d’augmenter la taille du VPS. La référence du système de fichiers proc du noyau documente les champs de mémoire derrière ces observations.

Identifier le système de fichiers qui se remplit réellement

df -h / /opt/first-api
df -i / /opt/first-api

La première commande indique l’espace sur les systèmes de fichiers contenant ces chemins. La seconde indique les inodes, enregistrements de système de fichiers nécessaires aux fichiers et répertoires. Une charge de travail avec de nombreux petits fichiers peut épuiser les inodes alors que la capacité en octets reste. Vérifiez le montage et les deux types de capacité plutôt que d’utiliser la taille de tout le VPS comme seul chiffre. Voir le manuel df de GNU.

Un chemin sur un volume monté séparément peut se remplir indépendamment du système de fichiers racine. Inversement, deux chemins listés peuvent appartenir au même système de fichiers, donc leur espace disponible ne s’additionne pas. Les réservations de système de fichiers, les quotas et les couches de stockage peuvent aussi affecter ce que l’application peut écrire. Un seul pourcentage affiché n’identifie pas le responsable de la croissance.

Attribuer la croissance aux journaux, aux téléversements ou aux artefacts

sudo du -xhd1 /var/lib/field-api
sudo du -xhd1 /var/log
sudo du -xhd1 /opt/field-api
sudo journalctl --disk-usage

GNU du estime l’espace alloué sous chaque répertoire. Ici -x évite de traverser un autre système de fichiers, -h utilise des unités lisibles et -d1 limite la profondeur affichée. Les grandes arborescences peuvent tout de même prendre du temps et de l’activité disque à analyser. Les erreurs de permission signifient que la vue est incomplète. Voir le manuel du de GNU. La commande journal indique le stockage du journal, y compris les fichiers actifs et archivés, comme documenté par journalctl.

Comparez les plus grands répertoires avec leur rôle :

• Journaux : une erreur répétée a-t-elle augmenté le volume, et la rotation est-elle configurée ?
• Téléversements : les fichiers utilisateur conservés augmentent-ils comme prévu, et les téléversements partiels abandonnés sont-ils pris en compte ?
• Artefacts de version : d’anciennes compilations s’accumulent-elles au-delà de la politique de retour arrière ?
• Fichiers de base de données : les outils propres à la base de données expliquent-ils la croissance et les besoins de maintenance ?

Ne supprimez pas un répertoire de base de données inconnu et n’utilisez pas un nettoyage large de volume de conteneur comme étape d’investigation. Identifiez d’abord la propriété, les exigences de conservation et une copie récupérable. Si df et les totaux des répertoires divergent fortement, inspectez les limites de montage, les erreurs d’accès et les fichiers encore ouverts après suppression avec un opérateur expérimenté ; supprimer à répétition des fichiers visibles peut manquer l’espace occupé.

Transformer les relevés en action suivante précise

Cas illustratif : la mémoire disponible reste confortable, mais un répertoire de téléversement croît d’environ 400 Mio sur chacun de deux jours observés. Le système de fichiers dispose d’environ 2 Gio disponibles. Diviser l’espace restant par cette croissance à court terme suggère seulement environ cinq jours au même rythme, avant de prévoir une marge de fonctionnement. Il s’agit d’une estimation de planification, pas d’une prévision ni d’une échéance sûre à attendre ; les téléversements et les travaux temporaires peuvent arriver de manière irrégulière.

L’action suivante consiste à vérifier la rétention des téléversements et la demande attendue, à planifier du stockage supplémentaire si c’est justifié, et à définir une alerte assez tôt pour agir. Davantage de RAM ne résoudrait pas ce constat. Dans un autre cas, une compilation de déploiement peut créer un bref pic de mémoire alors que la diffusion reste faible ; déplacer la compilation hors du VPS pourrait être plus utile que d’agrandir définitivement l’environnement d’exécution.

Après une modification justifiée, répétez les mêmes relevés et une action applicative. Confirmez que l’espace est réellement disponible et que les données prévues fonctionnent encore. Gardez la suppression et le redimensionnement comme opérations planifiées avec des étapes de récupération, et non comme des réponses automatiques à un chiffre rouge. Utilisez le guide de budget de ressources pour transformer un besoin démontré en choix de configuration, et entraînez-vous à la restauration avant de dépendre d’un nettoyage ou d’une migration.