Heap snapshot on OOM due to buffers/external memory/large arrays rather than V8 heap
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 35/100
- Type d'issue
- Fonctionnalité
- Clarté
- À clarifier
- Activité
- Calme
- Stack technique
- javascript, node.js
- Domaine
- backend, operating-systems
Piste de recherche
L’issue ne nomme aucun fichier source ni aucun test. Commencez par examiner la gestion par Node de --heap-snapshot-on-oom et de process.memoryUsage(), puis déterminez comment sont représentées les limites du tas V8, de Buffer, de la mémoire externe et de RSS ; la tâche ne pourrait être considérée comme terminée qu’avec une conception arrêtée, une implémentation et une couverture de tests pour le comportement proposé de --max-memory ou --max-rss.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
What is the problem this feature will solve?
I have a server that's been OOMing when it hits the Docker memory limit I set of 2GB. I had set --max-old-space-size=432 --max-semi-space-size=16 --heap-snapshot-on-oom but Node isn't logging OOM or creating a heap snapshot so I think the issue is too much buffer allocation.
It sure sucks that there's no surefire way to get diagnostic information if too many buffers get allocated.
What is the feature you are proposing to solve the problem?
I'm not 100% sure if this is possible but a --max-memory or --max-rss flag that would set a limit on the resident set size would be really great. If V8 heap, buffer, or C++ external object allocation would push the resident set size over this limit, Node would make a heap snapshot if --heap-snapshot-on-oom is set, and then exit.
What alternatives have you considered?
I will have to try polling process.memoryUsage() and taking my own heap dump if the memory is getting too large, but I think sudden buffer allocation is OOMing after only a few seconds so I'm not sure it will even work.
- Langage dominant
- JavaScript
- Étoiles
- 122k
- Forks
- 37.4k
- Merge moyen
- 4 j 12 h
- PR mergées (30 j)
- 296
Préparer son environnement
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de nodejs/node
-
doc
Difficulté 1/5 Moins d'une heure Accessibilité débutants 90/100
Les mainteneurs répondent en général sous 1 jour
-
doc
Difficulté 2/5 1-3 heures Accessibilité débutants 65/100
Les mainteneurs répondent en général sous 1 jour
-
build
Difficulté 1/5 Moins d'une heure Accessibilité débutants 88/100
nodejs/node#66076 · 2 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 84/100
nodejs/node#65994 · 2 commentaires · 2 réactions ·
Les mainteneurs répondent en général sous 1 jour
-
feature request
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
nodejs/node#63841 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de nodejs/node
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 90/100
Les mainteneurs répondent en général sous 1 jour
-
Design only Leadership Survey SLFS
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
bcgov/digital-journeys#2293 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
tursodatabase/turso#9405 ·
Les mainteneurs répondent en général sous 1 jour
-
Toolkit
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100
Les mainteneurs répondent en général sous 1 jour
-
API Bug
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
ProjectSidewalk/SidewalkWebpage#5556 ·
Les mainteneurs répondent en général sous 1 jour