13 commentaires
J'ai audité mes dépendances, rien de flagrant. Mais j'utilise beaucoup de buffers partagés entre le main thread et les worker threads.
Tente de lancer ton processus avec --max-old-space-size restreint pour forcer le GC. Si ça crash plus vite, c'est que ton heap est saturé par des références fantômes.
Utilise heapdump pour générer un snapshot au moment où la mémoire commence à monter. Compare deux snapshots avec Chrome DevTools pour isoler les objets qui persistent.
Bonne idée, je vais essayer de comparer les snapshots. Je suspecte un EventEmitter qui garde des listeners actifs sur des objets qui devraient être détruits.
Et côté jemalloc, as-tu ajusté les variables d'environnement MALLOC_CONF ?
J'ai testé avec background_thread:true,metadata_thp:auto, ça a un peu stabilisé le RSS, mais le problème de SIGSEGV persiste.
Si c'est un SIGSEGV, c'est probablement un accès mémoire invalide. Tente de lancer ton app sous valgrind en staging, même si c'est lent, ça te donnera l'adresse exacte du fault.
Je vais faire ça. Je vous tiens au courant si le core dump révèle un pointeur nul dans l'un de mes bindings natifs.
Tiens-nous au courant, c'est le genre de bug qui rend fou.
Verdict : c'était bien une bibliothèque native obsolète qui tentait d'écrire dans un buffer déjà libéré par le GC. Mise à jour effectuée, le crash a disparu.
Laisser une réponse
Vous devez être connecté pour poster un message !
Salut à tous, je fais face à un problème étrange sur un service critique en production. Mon processus Node.js subit des crashs aléatoires avec un signal
SIGSEGVsans aucune stack trace explicite dans les logs. Après avoir activéjemallocpour gérer l'allocation mémoire, je vois des pics de fragmentation énormes.Est-ce que quelqu'un a déjà réussi à corréler des fuites mémoire natives avec des objets JavaScript qui ne sont pas correctement libérés par le garbage collector ?