NodeJS : Comment déboguer “EventEmitter fuite de mémoire détecté. 11 auditeurs ajoutée”

Comment puis-je déboguer mon application qui affiche cette erreur:

(node) warning: possible EventEmitter memory leak detected. 11 listeners added. Use emitter.setMaxListeners() to increase limit.
Trace
    at Socket.EventEmitter.addListener (events.js:160:15)
    at Socket.Readable.on (_stream_readable.js:653:33)
    at Socket.EventEmitter.once (events.js:179:8)
    at TCP.onread (net.js:527:26)

Je ne pouvais pas trouver de l'hypothèse d'une fuite de l'objet pour l'augmentation de l'auditeur limite par .setMaxListeners(0);

SOLUTION (à partir de fardjad et jan salawa)

Avec jan salawa de recherches j'ai trouvé un travail de bibliothèque (longjohn) pour augmenter les traces de pile détaillé. Avec fardjad la réponse que j'ai trouvé que nous avons pour le prototype EventEmitter.addListener ET EventEmitter.on.

Avec la solution que je pourrais obtenir cette nouvelle trace:

(node) warning: possible EventEmitter memory leak detected. 11 listeners added. Use emitter.setMaxListeners() to increase limit.
Trace
    at EventEmitter.addListener.EventEmitter.on (xxx/main.js:44:15)
    at Readable.on (_stream_readable.js:653:33)
    at ServerResponse.assignSocket (http.js:1072:10)
    at parser.onIncoming (http.js:1979:11)
    at parserOnHeadersComplete (http.js:119:23)
    at socket.ondata (http.js:1912:22)
    at TCP.onread (net.js:510:27)
  • Check this out à propos de l'agent.maxSockets weblog.bocoup.com/node-stress-test-analysis . Peut-être que c'est une cause.
  • Essayé, sans succès. J'ai mis require("http").globalAgent.maxSockets = Infinity; à mon main.js mais rien n'a changé ... 🙁 j'ai aussi essayé ulimit -n 999999 de commande pour ouvrir le fichier limite et -–nouse-idle-notification pour suspension en temps réel garbage collector ...
  • Cela a complètement raccroche mon nœud de serveur js comme une exception lors de l'exécution sur le plan local lorsque j'appuie sur ctrl + C autre traitement de démarrer. J'ai essayé de réglage maxListeners pas utiliser, Qu'est-ce qu'il dit est-il que j'ai aussi beaucoup de gars connectés à la même auditeurs ou est-il en me disant que j'ai trop d'événements
InformationsquelleAutor Ifnot | 2013-03-23
  1. 32

    Il s'avère que c'est un bug dans nodejs, nous parlons de ce problème ici : https://github.com/joyent/node/issues/5108

    Solution pour buggé serveurs http thats jeter un EventEmitter memory leak detected et remplir la mémoire disponible /disponibles en temps de calcul :

    Revenir à l'ancienne version v0.8.23. (Vous pouvez télécharger et installer/compiler à partir d'ici : http://blog.nodejs.org/2013/04/08/node-v0-8-23-legacy/)

    Mise à JOUR 2018 : je vois plusieurs retours sur ce sujet alors que le problème semble avoir disparu depuis des années. Notez que cette réponse est seulement pour une fuite d'un serveur http de construire avec nodejs. Si vous êtes dans un autre scénario, s'il vous plaît regarder les autres réponses sur ce fil et ne pas faire le downgrade de version (comme l'a suggéré sur cette réponse), vous perdrez votre temps.

    • Merci pour la mise à jour 🙂
    • ^ ce! .......
    • Je vais essayer de garder tout le monde posté sur la plus récente version de travail de nœud une fois ils ont certainement résoudre ce problème. Je suis encore en train de problèmes avec elle.
    • pourquoi est-il fermé lorsque le bug est toujours là, dans v0.10.24!?
    • toujours dans la v0.10.26
    • Je suis maintenant dans v0.10.31 !
    • Je vais voir cela avec v0.10.32
    • Présent dans v0.10.33 ainsi
    • Et je viens de recevoir cette erreur dans v0.10.35 nouveau!
    • 10.34 sur et en ont encore
    • Confirmer - c'est dans v0.10.33 - j'ai juste couru un vieux script développé dans les 0,8 jours pour la première fois depuis des lustres, et BOOM... recherche m'a conduit tout droit ici. Oh, eh bien, le temps de le tester en "io.js" alors, je le crains, fonctionne correctement (vous Êtes la lecture de ce joyent!)
    • il l'a fait un travail sur ok io.js?
    • Désolé de ne pas pouvoir vous donner une réponse honnête, je n'ai pas encore eu la chance de le tester.
    • Je vois le même symptôme dans iojs (v1.3.0) et le nœud (v0.12.2)
    • même en v5.2.0 ...
    • toujours sur v0.10.37
    • Une solution semble être ici (pas testé): github.com/angular-fullstack/generator-angular-fullstack/issues/...
    • et même dans 6.2.2
    • et le nœud v5.12.0 avec npm 3.10.7
    • passe encore avec nœud v5.9.1 et npm v3.10.7
    • Nœud v6.10.0, mnp: 4.6.1 Toujours de voir ça maintenant 🙁
    • de voir sur les v8.11.3 (noeud:14) MaxListenersExceededWarning: Possible EventEmitter fuite de mémoire détecté. 11 réveil auditeurs ajouté. L'utilisation de l'émetteur.setMaxListeners() pour augmenter la limite de

    InformationsquelleAutor Ifnot
  2. 12

    Pour moi, ça ressemble à la boucle d'événement est bloqué. Cela peut se produire si vous faites l'uc tâches node.js boucle d'événements. Vous pouvez utiliser processus enfant faire tâche intensive.

    Vous pouvez vérifier ce qui est bloquant node.js à l'aide de méthodes suivantes:

    1. Mesure du temps de calcul de chaque appel. Journal si le temps est élevé, donc vous savez app est défaillante.
    2. Mis en place un journal de planification de sorte que vous savez quand quelque chose boucle de blocage

      function timeTick() {
    var startTime = (new Date().getTime());
    function onTick() {
        var interval = (new Date().getTime()) - startTime;
        if(interval > 5)
            console.log('timeTick(): WARNING: interval = ' + interval);
    }
   process.nextTick(onTick);
}
setInterval(timeTick, 1000);
    3. Utilisation de profil.
    4. Utilisation cette pour l'enregistrement et du profilage. C'est bibliothèque utilisée dans Nodejitsu.
    • Oui, ce problème est à partir d'un objet avec un trop grand nombre d'auditeurs ajouté lors de la tâche intensive. Mais j'ai trouver la sorcière de l'objet et de l'augmentation de l'auditeur limite ! La question est de savoir comment trouver d'où vient le problème ?
    • Je n'étais pas sûr si vous faites l'uc tâche. J'ai édité mon post.
    • Lors de la lourde tâche de manutention (nombre de connexions) CPU ne va pas jusqu'à de 20% d'un core. Mais après l'erreur se produit, le programme de commencer à utiliser 100% du CPU et croissante de la mémoire.
    • Ok pouvez-vous montrer comment êtes-vous de la manipulation de ces connexions sur le serveur?
    • Mon point est que le problème peut être quelque part d'autre.
    • Je ne sais pas si vous exportez le seul lien de la manipulation va vous aider. Le problème peut également vient de connexion dépendante je pense ...
    • laissez-nous continuer cette discussion dans le chat
    • Découvrez ces sujets, la façon de traiter avec la boucle d'événement de blocage: groups.google.com/forum/?fromgroups=#!topic/nodejs/GWD1ve9W5_k , grokbase.com/t/gg/nodejs/1232z2xchk/...
    • J'ai essayé toutes les solutions : 1 ne Pourrais pas obtenir de travail intéressante pour la arpentage. 2 rien ici aussi, il y a déjà 0 durée. 3 profil est trop vieux et ne pouvait pas le faire fonctionner avec le noeud v0.10. 4 Je suis en train de l'utiliser pour les bas niveau debogging. (Je suis edditing mon post original)

    InformationsquelleAutor
  3. 10

    C'est exactement ce qui m'est arrivé. Pour moi, je imbriquée un écouteur d'événement dans un autre écouteur d'événement accidentellement.

    Regardez votre code et assurez-vous que vous N'avez PAS un écouteur d'événement bloc DANS un autre écouteur d'événement bloc par exemple(à moins que vous le faites exprès):

    socket.on('data', function(data) {
//code goes here

socket.on('close' , function() {
//code goes here
     });

   });

    Dans le mauvais exemple ci-dessus, le socket.sur ('close') l'auditeur doit être en DEHORS de la prise.sur('data') bloc.

    Dans mon cas, lorsque j'ai reçu 5 flux de données, de la prise de courant.sur ("fermer") auditeur est en attente pour un gros événement se produise. Quand je ferme une fois, une autre 4ème événement de clôture à l'exécution. Ce n'est clairement pas ce que je voulais. Cela est dû à la nature de Node.js ce qui est non-bloquante. Il mémorise les événements dus à la fonction de rappel.

    • Ce fut la cause de racine de mon erreur trop! J'ai eu somereaderstream.on("close", function(){ fstream.Reader({ 'path': basepath, 'type': 'Directory' }).on("end", function(){ ..... }); }); Thanks for pointing out!
    InformationsquelleAutor fadleen
  4. 6

    J'ai essayé de créer le prototype de la EventEmitter pour l'ajout de messages de log dans
    addListener mais je ne pourrais pas obtenir de travail

    À crochet addListener vous pouvez faire quelque chose comme ceci:

    //on the first line of your main script
var events = require("events"),
    EventEmitter = events.EventEmitter;

var originalAddListener = EventEmitter.prototype.addListener;
EventEmitter.prototype.addListener = function (type, listener) {
    if (this.listenerCount(this, type) >= 10) {
        //TODO: PLACE YOUR CODE FOR DEBUGGING HERE
    }
    originalAddListener.apply(this, arguments);
}
    • Il ne fonctionne pas. Le hook est appelé pour certains de mes app auditeurs, mais pas tous les auditeurs. Malheureusement, la addListener sorcière de feu l'erreur de ne pas exécuter le crochet (j'ai essayé de vous tous listerners retrait de l'état). Est-ce crochet de fixation sur les modules events.EventEmitter.addListener ? (peut-être que le problème vient d'un "mauvais" module j'utilise ?)
    • Le problème pourrait être causé par une mauvaise module, mais node.js caches modules. De multiples tentatives de require un module (normalement) charge le module une fois. Donc, si vous installez le crochet de votre script principal, d'autres modules devraient utiliser accroché addListener.
    • Vous avez raison, j'ai essayé de mettre votre code dans certains modules, et le résultat de la même : j'ai eu 20/30 auditeurs sur différents objets au début de mon appli et rien, quand l'erreur apparaît :(.
    • Pour vraiment travailler, nous devons prototype EventEmitter.addListener ET EventEmitter.on en même temps.
    • Belle pensée...
    InformationsquelleAutor fardjad
  5. 5

    Cette alerte sera levée si vous vous inscrivez à un événement particulier, d'un même objet à plus de 11 fois.

    Vérifier si vous avez de la " sur " appel à particulier de l'événement dans une fonction que vous appelez fréquemment, ce qui conduit à l'inscription pour un événement à plusieurs reprises.

    Cette lien m'a aidé à le comprendre.

    • Il devrait être plus de 10 fois'.
    • Merci, cela a aidé! J'ai une application avec play() et stop() méthodes. J'ai un EventEmitter d'envoyer un "signal d'arrêt" lorsque stop() est appelée, ce qui tue un processus (lecteur vidéo). Problème est que, si j'ai appelé play() 11 fois: le processus semble avoir tous les joueur processus enregistré comme toujours ouverte (même si elles ne le font pas), donc j'avais besoin de tuer tous les processus avant de commencer un nouveau.
    InformationsquelleAutor Vishwanath gowda k
  6. 2

    Depuis le nœud 6, vous devez utiliser node --trace-warnings: https://nodejs.org/api/cli.html#cli_trace_warnings

    InformationsquelleAutor nicojs
  7. -1

    J'ai rencontré le même problème lors de l'essai de Réagir composants à l'aide de moka et enzyme.

    J'ai pu résoudre mon problème en faisant explicitement le démontage des composants après que j'ai fini les tests.

    Le problème était que j'étais composants de montage à plusieurs reprises dans mes tests, qui ont été l'ajout de plus d'auditeurs, jusqu'à ce que le nombre d'auditeurs ai 11 ans, et j'ai reçu un avertissement.

    J'ai changé mon code de test en ajoutant le rendus.démonter() ligne. Le problème est résolu pour moi.

    describe('<CircleArc />', () => {

    it('renders', function () {
        const rendered = mount(<CircleArc />);
        assert.ok(rendered.find('path'));
        rendered.unmount();
    });
}
    InformationsquelleAutor brendangibson