Le playbook des fuites mémoire Node.js — heap snapshots, clinic.js et les quatre patterns que nous trouvons sans cesse

Les fuites mémoire Node.js tendent à paraître terrifiantes et ne le sont généralement pas. Les mêmes quatre patterns apparaissent dans audit après audit : un Map/Set qui grossit sans limite, une closure qui retient un scope parent étonnamment grand, des event listeners attachés mais jamais retirés, et un cache in-process sans policy d'éviction.

Voici le playbook de diagnostic que nous appliquons aux services Node clients qui se mettent à manger de la mémoire semaine après semaine.

Heap snapshots — le seul diagnostic qui n'est pas de la devinette

import v8 from 'node:v8';
import fs from 'node:fs';
 
process.on('SIGUSR2', () => {
  const file = `/tmp/heap-${Date.now()}.heapsnapshot`;
  v8.writeHeapSnapshot(file);
  console.log('wrote', file);
});

Envoyez SIGUSR2 au processus, prenez un snapshot, répétez après 30 minutes de trafic, diffez les deux dans l'onglet Memory de Chrome DevTools. La colonne retained-objects vous dit exactement ce qui grandit.

L'article complet couvre :

• Les quatre patterns et comment chacun apparaît dans le diff de heap snapshot
• clinic.js doctor et clinic flame pour CPU + mémoire ensemble
• --inspect et Chrome DevTools pour profiling live en non-prod
• Faire tourner la détection de fuites contre vos propres services en CI avant la prod
• La lecture cgroups + OOMKiller quand la fuite est partie en prod malgré tout
• Quand la « fuite » est en réalité la young generation de V8 qui ne collecte pas assez vite (ce n'est pas une fuite)

Contactez-nous si votre service Node a discrètement grandi et que personne ne sait pourquoi.