Trouver une fuite de mémoire avec des instantanés tracemalloc

Objectif

Attribuer la croissance de mémoire d'un processus Python de longue durée aux lignes source qui l'allouent, en n'utilisant que la bibliothèque standard.

Prérequis

Un cas de reproduction (une boucle, une séquence de requêtes ou une tâche après laquelle la mémoire résidente est plus élevée qu'avant), la possibilité de redémarrer le processus avec une variable d'environnement ou un indicateur, et Python 3.

Étapes

1. Démarrer le traçage avant l'exécution du code suspect : PYTHONTRACEMALLOC=25, -X tracemalloc=25, ou tracemalloc.start(25), aussi tôt que possible. Le nombre est la profondeur de la pile d'appels conservée par allocation ; la documentation indique que la valeur par défaut est une seule trame, qui ne nomme que la ligne allocatrice, et que davantage de trames sont nécessaires pour regrouper les statistiques par pile d'appels complète.
2. Monter en charge : exécuter l'opération plusieurs fois pour que les imports, les caches et les pools de connexions atteignent un état stable, puis prendre s1 = tracemalloc.take_snapshot().
3. Exécuter l'opération un nombre connu de fois, par exemple 100, et prendre s2.
4. Filtrer le bruit comme dans l'exemple de la documentation : s.filter_traces((tracemalloc.Filter(False, "<frozen importlib._bootstrap>"), tracemalloc.Filter(False, "<unknown>"))).
5. Comparer : for stat in s2.compare_to(s1, "lineno")[:10]: print(stat). Les entrées sont triées par différence de taille absolue ; une fuite se manifeste par une ligne dont size_diff et count_diff évoluent proportionnellement au nombre d'itérations. Relancer avec la clé "traceback" et afficher stat.traceback.format() pour voir qui a atteint cette ligne.
6. Confirmer avec un nombre d'itérations différent : une fuite croît proportionnellement, un cache atteint un plateau.
7. Pour des pics plutôt qu'une croissance, entourer le bloc avec get_traced_memory() (valeur courante et pic) et reset_peak(), comme le fait l'exemple de la documentation.
8. Conserver avec snapshot.dump(path) afin qu'une autre personne puisse faire Snapshot.load(path) et inspecter sans reproduire le cas.

Résultat attendu

Une courte liste de lignes source avec la croissance par itération et le chemin d'appel qui les atteint ; les coupables habituels sont une liste ou un dictionnaire auquel on ajoute sans jamais l'élaguer, un cache non borné, des objets retenus par une fermeture (closure) ou par lru_cache sur une méthode, et des gestionnaires enregistrés de façon répétée.

Limites et base de vérification

tracemalloc ne voit que les allocations effectuées via les allocateurs de Python ; la mémoire que les bibliothèques C allouent directement et la fragmentation du tas sont invisibles, si bien que la taille résidente peut croître alors que la taille tracée ne le fait pas. Le traçage coûte de la mémoire et du CPU, qui augmentent avec la profondeur des trames (la documentation propose get_tracemalloc_memory() pour le mesurer), donc à utiliser dans un cas de reproduction plutôt que durablement en production. La procédure suit la documentation citée ; aucune mesure n'est revendiquée.