The server in question is not an http server, but a back-end simulation server running physics simulation for an online game using a Bullet native library. Yeah, I know, not exactly a typical (or perhaps wise...) use of node.js. We're 95% certain the Bullet module is the culprit, but that is hundreds of thousands of lines of 3rd party C++ code, not something feasible to poke in, and, like most physics simulations, not particularly deterministic when combined with the randomness of network latency and real user actions. Stand alone stress tests we've tried never exhibit the problem, and since it takes a fully loaded server a day to exhibit it, it's not likely to reproduce in a development environment. That being said, it consistently does reproduce on the production servers, so that is, theoretically, an easy way to debug it with post-mortem debugging (albeit with a day-long turn-around to test fixes). Heap dumps are a much more reliable way of tracking down heap issues in a large system than any "poke at different parts of the system at random" method, I was just hoping there was an easy way to get them reliably...
I'll try poking around in a gdb dump, although I'm guessing the default heap isn't going to have any allocation site information on the heap entries, but it might show some useful information, at least it should allow me to quickly sample the heap to determine what the primary content type is (strings, floats, ints, etc) is that's leaking, which may provide some insight. On Mar 16, 8:34 am, George Stagas <[email protected]> wrote: > You can pinpoint the leak by writing stress tests. Don't wait days for > the leak to show in production. Find which component causes it. Make a > list of suspects. If it's an http server, start with simple requests. > Does the memory go up? No? Maybe it's the db? Try a million > read/writes. Did you find the component that leaks? Follow the chain > of events, commenting out suspicious code and trying again until the > leak disappears. > > 2012/3/16 robot1125 <[email protected]>: > > > > > > > > >> So, my general question, how do people go about debugging memory leaks > >> in native code in node (or node itself)? > > > You may find this interview with Brian Cantrill of Joyent interesting. > > >http://www.infoq.com/interviews/operating-nodejs-production-bryan-can... > > > He discusses some of the tools they use to debug node apps in > > production at Joyent. Some of them require running under their > > homebrew OS, but the discussion may give you some ideas. > > > -- > > 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 [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > For more options, visit this group at > >http://groups.google.com/group/nodejs?hl=en?hl=en -- 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
