Profiling Node.js 2014

[Samuel Gómez]

Hi, I'm trying to follow
http://blog.nodejs.org/2012/04/25/profiling-node-js/
on
* Ubuntu 14.04
* Node compiled from github source on yesterday
to get a flame graph of a node program.

But I fail on step 2.

dtrace -n 'profile-97/execname == "node" && arg1/{
    @[jstack(150, 8000)] = count(); } tick-60s { exit(0); }' > stacks.out

In my case writes this on stacks.out:
Usage /usr/bin/dtrace [--help] [-h | -G] [-C [-I<Path>]] -s File.d [-o <File>]

Also, doing a man dtrace I see that there is no -n option.

So I'd say that that post is outdated. But also I've read that dtrace for linux kind of sucks, so I'm not sure what's going on.

Also I've seen this problem is quickly mentioned here
http://logs.nodejs.org/node.js/2014-02-19
but not solved.

Please, do you know if there is still a way to get a flamegraph from node on Linux?

Thank you!

[Trevor Norris]

If you're using master the you don't have to use dtrace. I have a rough outline here of how to create flame graphs: https://gist.github.com/trevnorris/9616784

[Andrei Karpushonak]

That post is not outdates, as still "You must gather data on a system that supports DTrace with the Node.js ustack helper. For now, this pretty much means illumos-based systems like SmartOS"

In other words, you will not make flame graph work on 14.04 Ubuntu.

[Arunoda Susiripala]

Trevor,

Does it show js stack traces?

is it possibly to apply this for a already running app? Without using perf record ?

On Sunday, June 15, 2014, Trevor Norris <trev....@gmail.com> wrote:

If you're using master the you don't have to use dtrace. I have a rough outline here of how to create flame graphs: https://gist.github.com/trevnorris/9616784

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: 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 unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/f75448b1-c526-4702-ba80-7dd86d4bcf60%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

---

Arunoda Susiripala

I curate Meteor Weekly - Check it out!

[Trevor Norris]

> Does it show js stack traces?

Yes. perf has JIT support. When the Node runtime flag is enabled the app will produce a .map file which contains the memory address and instruction information necessary to fill in the blanks.

> Is it possibly to apply this for a already running app?

AFAIK the application must be started with the correct option. Though there may be an API that allows the user to toggle this functionality. If not, then it would be useful to create a ticket upstream to support it.

> Without using perf record ?

This one confuses me. perf record is what allows you to collect the data necessary to create the flame graph. Unless you use dtrace. Those are the only two options I know of so far.

[Arunoda Susiripala]

On Tue, Jun 17, 2014 at 11:00 AM, Trevor Norris <trev....@gmail.com> wrote:

> Does it show js stack traces?

Yes. perf has JIT support. When the Node runtime flag is enabled the app will produce a .map file which contains the memory address and instruction information necessary to fill in the blanks.

That's nice. I'll give this a try today.

 

> Is it possibly to apply this for a already running app?

AFAIK the application must be started with the correct option. Though there may be an API that allows the user to toggle this functionality. If not, then it would be useful to create a ticket upstream to support it.

I'll check. Anyway, it's okay to run with an option. 

 

> Without using perf record ?

This one confuses me. perf record is what allows you to collect the data necessary to create the flame graph. Unless you use dtrace. Those are the only two options I know of so far.

This is what I asked: is it possible to ask perf to record by simply giving a PID rather start the node app as follow.

perf record -i -g -e cycles:u -- ~/sources/node/node --perf-basic-prof script.js

 

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: 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 unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/01d7745b-a845-4205-ad24-4e3101b1f42d%40googlegroups.com.

[Arunoda Susiripala]

Trevor, 

I was able to try this out.

Did some small tweaks to your script: https://gist.github.com/arunoda/09a7f154a130e3d04c89/revisions

---

Arunoda Susiripala

I curate Meteor Weekly - Check it out!

[Samuel Gómez]

Hi Trevor,

Thanks a lot. It works.

I'm trying to profile synchronous and asynchronous code.

The flame graph for synchronous code is very clear because you can see all the stack of functions, just as in the code. This makes trivial to, from the graph, finding the involved code.

However, apparently the flames for asynchronous code are always contained within "emit events.js:68", without a reference to the original "user" caller code.

I've tried to give a name to the anonymous functions I had in there just in case that helps, but it does not. These new names appear on the SVG source code but not containing anything, so their width is sub-pixel.

So, do you know of a technique to know which are the functions that provoke the call to async code? So for example, the name of the caller would be included on the "emit events.js" spans, or on their first child.

I hope the question makes sense.

Thank you.