WHAO!!!!! if this is not a complete answer, I do not know what is. Thank you so much. I am going to study your reference materials.
Much appreciated. Regards, Reza On Wed, Apr 30, 2014 at 3:11 PM, Timothy J Fontaine <tjfonta...@gmail.com>wrote: > Finding memory leaks in a moderately complicated program written in a > statically typed language is hard, change to a dynamic language, > JIT'ed code, garbage collection, and closures -- and well, damn, it's > hard. > > You're simply not going to be able to use a static analyzer pass on > JavaScript to identify all "memory leak". > > Keep in mind that what you're generally chasing down in JavaScript is > not actually a "memory leak", but rather a resource leak. In other > words, you're holding onto an object for longer than what you had > anticipated. A lot of times because of a function closure is holding > the resources in its parents scope, and you forgot about that part. > > Ugh. > > You picked this language because it had functions as first class and > supported closures, and now it's getting in your way! > > The best thing you can do to combat resource leaks is to write cleaner > code. Start by avoiding closures, and maybe use a control flow library > that makes that part easier for you. If you can think more in a stack > based way, that is passing your state to the functions, you know > exactly how much state you're carrying with you. And hopefully you > will stop carrying all that extra state around. > > As an aside I think Node's best control flow library, is our flow > control abstraction -- Streams. > > That being said, let's say you have an application in production today > and you want to track down a resource leak, you want to find out what > it is exactly you're keeping around. I've had to do this a lot [1]. So > have a lot of my colleagues at Joyent, and they have written a bunch > of tooling around it to make it easier [2] [3]. It's all open source > [4]. And the tooling works with artifacts that are generated on Linux > as well [5]. > > It's all done with postmortem analysis, that is using a core file > after the fact, which is ideal because if you knew you were going to > have a problem before going into production you probably just wouldn't > have gone into production before fixing the problem. The benefit here > is that if node runs out of memory it will generate a core file, and > you can debug that in place and figure out what went wrong. > > There are other solutions that people use, things like the module > heapdump [6] for example, this requires though that you knew in > advance you were having a memory problem, and could add another > module, and that you invoked a heapdump in time before the process > died. Once that's done you can load that file into chrome's inspector > tools to browse the heap. That can be painful if the file is > particularly large. > > Hopefully some of this information helps, let me know if there's > anything else you need. > > [1] http://www.joyent.com/blog/walmart-node-js-memory-leak > [2] http://www.joyent.com/developers/node/debug > [3] http://www.joyent.com/developers/node/debug/mdb > [4] https://github.com/joyent/illumos-joyent > [5] http://www.joyent.com/blog/mdb-and-linux > [6] http://npmjs.org/package/heapdump > > On Wed, Apr 30, 2014 at 8:58 AM, Reza Razavipour > <reza.razavip...@gmail.com> wrote: > > I have no tool to help me detect memory leaks in my node server. I use > > WebStorm for my development. > > In other languages, like C++, I know what causes a leak and how to guard > > against them. > > I do not know what leaks memory. How do I got about putting such a list > > together for my programming discipline? > > What tools do you recommend for detection? > > > > -- > > -- > > Job Board: http://jobs.nodejs.org/ > > Posting guidelines: > > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > > You received this message because you are subscribed to the Google > > Groups "nodejs" group. > > To post to this group, send email to nodejs@googlegroups.com > > To unsubscribe from this group, send email to > > nodejs+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/nodejs?hl=en?hl=en > > > > --- > > You received this message because you are subscribed to the Google Groups > > "nodejs" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to nodejs+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to nodejs@googlegroups.com > To unsubscribe from this group, send email to > nodejs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to a topic in the > Google Groups "nodejs" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/nodejs/L7RD0bRe9f8/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > nodejs+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
