node.js memwatch追逐内存泄漏

Question

I've been chasing a pretty bad memory leak in a node program.

I'm using the memwatch module HeapDiff() to try to identify the offending objects.

HeapDiff's report shows two suspect elements in the details array, ("Array" and "String", each of which have grown considerably.

I'm officially lost and have no idea how to narrow down the possible culprits. There are dozens of google-able howtos but none of them make any sense to me. The program in question uses quite a few 3rd party modules including carrier, dequeue and mqtt. It's 318 lines of code so I've not posted it.

I'd appreciate any pointers as to what my next step should be...

Here's an extract of the memwatch HeapDiff dump:

   {
    "before": {
        "nodes": 25312,
        "time": "2014-09-01T10:59:24.000Z",
        "size_bytes": 3596320,
        "size": "3.43 mb"
    },
    "after": {
        "nodes": 125705,
        "time": "2014-09-01T11:14:24.000Z",
        "size_bytes": 20255728,
        "size": "19.32 mb"
    },
    "change": {
        "size_bytes": 16659408,
        "size": "15.89 mb",
        "freed_nodes": 674,
        "allocated_nodes": 101067,
        "details": [
           {
                "what": "Array",
                "size_bytes": 348440,
                "size": "340.27 kb",
                "+": 1592,
                "-": 295
            },
            {
                "what": "String",
                "size_bytes": 12580056,
                "size": "12 mb",
                "+": 50329,
                "-": 20
            }
        ] 

Answer 1

Without code samples, it's hard to get into detail, but at a high level...

What I did was look not just at the categories that were biggest (because mine were also Array and String[1]) but looked for object types I could track down; find rows that have any notable growth at all and unique looking "what" entries, then find where those are in your code. Make new diffs around your usage of those, and narrow in or spread out until you find your growth points.

If you can't find suspect-looking object names, just divide your main execution path into two or three parts and run HeapDiffs for each of those. (what are you currently using to trigger your HeapDiff? startup and .on('leak')?)

1. By the way, that's not saying there's a single string that's 12mb. It's saying there are 12mb worth of strings -- actually, 12mb more of strings than there were at the front end of the diff. Those 12mb are spread out over the 50329 new strings. So, still, they're reasonably large.

Answer 2

May I suggest you to try the IDDE tools and see if this will help you to track down the leak? please see this [link]:( What diagnostic tools are available for Node.js applications? ) for some information. If you need more information to get started, I am more than happy to help.