Menu
If I use gcore to make a code dump of a Node.js process, what are the best tools to analyze it?
Inspired by: Tool for analyzing java core dump
In my specific case, I'm interested in investigating some memory leaks, so I'm really curious to get some heap analysis. General tools and even instrumentation packages and techniques are also welcome. I'm finding Node.js to be very interesting, but the runtime analysis tools are just not there yet.
309
With a core file, we can use the debugger (GDB) to inspect the state of the process at the moment it was terminated and to identify the line of code that caused the problem. That's a situation where a core dump file could be produced, but it's not by default.
core. <number> files are typically memory dumps created on Linux systems. The <number> is the Process ID of the process that crashed. I guess your Node. JS application has crashed a number of times and these are the memory dumps left there for you to debug.
Select Run | Open Core Dump from the main menu or call this action from Help | Find Action ( Ctrl+Shift+A ). If there are no Core Dump Debug configurations in the project, the Open Core Dump dialog will be shown right away. Otherwise, select New Core Dump from the popup menu.
When an application crashes, you can arrange for its state to be saved to disk, in a core dump file, which can indicate where the error occurred in the source code, the contents of memory at the time of the error, and the values of any variables and expressions set at the time.
For investigating crashes, I've found node-segfault-handler to be invaluable. It's a module I cooked up to get a native-code stack trace in the event of a hard-crash with a signal - eg deref of NULL leading to SIGSEGV
For investigating memory / allocation issues, here's some of the data I've collected thus far:
1) Blog post by Dave Patheco - the author talks about using a plugin to MDB for getting JS stacks and such. Sadly, as far as I can tell, the source of that plugin was never released (nor any binary form).
2) Postmortem Debugging in Dynamic Environments - ACM Queue article also written by Dave Patheco (linked from the blog post). While it makes for GREAT background reading, the article doesn't have many concrete tools and techniques in it.
3) node-panic - A pure-JS tool for dumping state in the event of an assert-failure type crash. Does nothing to help debug crashes that originate from native code faults (SIGSEGV, etc)
4) Joyent: Debugging Production Systems - talk by Bryan Cantrill on the tools and techniques he recommends (thx crickeys).
168
On Linux and Mac you can use llnode a plugin for the lldb debugger. The project is available under the nodejs organization on github:
https://github.com/nodejs/llnode
You can install from source via github or use brew on Mac. The readme on github should help you get it installed and there's an introductory blog article here:
https://developer.ibm.com/node/2016/08/15/exploring-node-js-core-dumps-using-the-llnode-plugin-for-lldb/
The original question was about memory analysis and the v8 findjsobjects and v8 findjsinstances commands will help there by generating a basic histogram of object counts and allowing you to list the instances of each type.
There's a full article on using llnode for memory analysis here: http://www.brendangregg.com/blog/2016-07-13/llnode-nodejs-memory-leak-analysis.html
28
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
