17

In the Java JVM, kill -3 forces the process to print the current stack traces of all running threads. I found it very effective to quickly locate bottlenecks.

Is there an equivalent in V8? Can I make V8 print the current stack trace?

Clarification: I assume, due to the asynchronous nature of node, it will be less useful than for a typical non-asynchronous program. Still, if there is an easy way to get access to a few stack traces, it does not take much time to look at it.

From my experience, some obvious bottlenecks can be quickly located that way before you need to switch to more advanced tools.

Philipp Claßen
  • 41,306
  • 31
  • 146
  • 239
  • @PaulDraper I don't know if it is just me but the Q seems to assume others have a fair idea of the use case of OP while using `kill -3` JVM. I would suggest you to propose an edit to get appropriate solution. – Aditya Guru Aug 25 '20 at 02:15
  • 1
    @AdityaGuru That here describes the idea (looking at stack traces, sometimes referred to as poor man's profiler): https://stackoverflow.com/a/378024/783510 – Philipp Claßen Aug 25 '20 at 09:07
  • 1
    @AdityaGuru a similar case is to debug a "hung" program. – Paul Draper Aug 26 '20 at 00:06
  • 1
    So the gist is 'it cannot be done' - at least not against an already running arbitrary NodeJS process, like what we *can* do with `kill -3`? – Janaka Bandara Apr 23 '21 at 10:02
  • 1
    @JanakaBandara I think so, too. There are certainly ways to identify performance problems in NodeJs, but they cannot be as easily applied in production as running "kill -3". My first approach when identifying performance in production tends to be to run "perf top" now. Sometimes it gives you a first clue, but there are obvious drawbacks: it does not understand NodeJs, so the output can be hard to interpret. Also, it monitors CPU usage, so it can be misleading for IO bound processes. It is still easy to run and does not slow down a production system too much, so I try it first. – Philipp Claßen Apr 24 '21 at 12:23

3 Answers3

2

Node has fully loaded diagnostics that tricks like above (if I understood correctly) would be redundant but feel free to correct me.

Must Read: Awesome blogs by NodeSource 1 2 3

I'll try to list down all the tools that I found useful:

Others (Just googled them.)

Aditya Guru
  • 646
  • 2
  • 10
  • 18
1

On this thread you have an idea using:

# node --debug-brk buggy.js
Debugger listening on port 5858

In another terminal:

# node debug -p $(pgrep -f 'node.*buggy')
connecting to 127.0.0.1:5858 ... ok
break in buggy.js:16
 14 }
 15 
>16 z();
 17 
 18 });
debug> cont

(wait for the node process to start using 100% CPU)

debug> step
break in buggy.js:3
  1 function x() {
  2     var i = 0;
> 3     while(1) {
  4             i++;
  5     }
debug> bt
#0 buggy.js:3:8
#1 buggy.js:9:2
#2 buggy.js:13:2
#3 buggy.js:16:1

Source: https://github.com/nodejs/node-v0.x-archive/issues/25263

chrki
  • 6,143
  • 6
  • 35
  • 55
zvi
  • 3,677
  • 2
  • 30
  • 48
1

You can accomplish the same using heapdump tool. I found the below article of the same which is below (It also works for me):

https://medium.com/better-programming/make-a-dump-of-the-v8-heap-and-inspect-for-your-node-app-b69f7b68c162

Viral Patel
  • 1,104
  • 4
  • 7