fren
Connexion

Comprendre les limites de ressources

3 min de lecture07 novembre 2026

Une application Python ne tombe pas seulement parce qu'elle contient un bug. Elle peut manquer de mémoire, être freinée par une limite CPU ou ne plus pouvoir écrire sur le disque. Distinguer ces trois cas évite de redimensionner l'offre au hasard.

1. Trois ressources, trois symptômes

Ressource Symptôme typique Mesure
RAM processus tué, code de sortie 137, MemoryError free -m, ps, memory.events
CPU réponses lentes, délais dépassés, file d'attente top, ps, temps de réponse
Disque écriture impossible, base corrompue, logs interrompus df -h, du

Une application peut consommer peu en moyenne et beaucoup en pic : import d'un gros fichier, génération de PDF, requête sans pagination. Dimensionnez sur le pic, pas sur le repos.

2. Mesurer et reconnaître l'épuisement

Sur un VPS Debian, les commandes de base :

Bash
free -m
ps -eo pid,comm,%cpu,%mem,rss --sort=-rss | head -n 10
df -h

Dans un conteneur système, les compteurs cgroup reflètent la limite réelle. Sur un système cgroup v2 :

Bash
cat /sys/fs/cgroup/memory.max
cat /sys/fs/cgroup/memory.current
cat /sys/fs/cgroup/memory.events

Un compteur oom_kill qui augmente confirme un processus tué faute de mémoire. Le code de sortie 137 correspond à SIGKILL, souvent prononcé par le noyau. À l'inverse, une limite CPU ne tue pas le processus : les requêtes ralentissent, les délais d'attente augmentent, mais le service reste vivant. Sur l'hébergement d'applications, la console et les graphiques du panneau donnent la consommation ; un redémarrage après un pic mémoire est un indice fort.

3. Réduire la consommation

  • Flux plutôt que chargement complet : lisez les fichiers par blocs, streamez les réponses volumineuses.
  • Pagination : ne chargez pas une table entière ; utilisez LIMIT et OFFSET.
  • Travailleurs : chaque processus Python a sa propre mémoire. Quatre workers coûtent environ quatre fois la base.
  • Caches bornés : une taille maximale et une politique d'éviction, sinon le cache devient une fuite.
  • Journaux : rotation et niveau INFO en production.
  • Données anciennes : archivez ou compressez ce qui n'est plus consulté.

Mesurez avant et après chaque changement. Sans chiffre de départ, aucune optimisation n'est vérifiable.

4. Choisir l'offre

Offre VPS RAM Usage raisonnable
Free 512 Mo tests, petit bot, site statique
Basic 2 Go API légère, un service Python
Pro 4 Go plusieurs services, base locale
Business 8 Go charges plus lourdes, plusieurs workers

Pour l'hébergement d'applications, les ressources dépendent de l'offre choisie. Comparez sur la page des tarifs et prévoyez une marge : un pic passager ne doit pas provoquer un OOM.

5. Vérifier

  1. Relevez la consommation au repos, puis sous charge réelle.
  2. Vérifiez memory.events après une journée d'utilisation.
  3. Testez le scénario le plus lourd avant de facturer une montée d'offre.
  4. Surveillez le disque : les logs et les fichiers temporaires sont les premiers coupables.

Publicité

Cet article vous a-t-il aidé ?

À lire aussi