Closed davidgatti closed 7 years ago
this is pretty much not going to work. i have never tested jstack and the user mode stuff may require more work. its good you got as far as you did, but advanced examples may simply not work.
On 11 December 2016 at 14:34, David Gatti notifications@github.com wrote:
You are my last hope ;) I'm having issue collecting some good data from NodeJS. I explained the problem on stackoverflow.com http://stackoverflow.com/questions/41060352/dtrace-is-not-collecting-any-data-for-nodejs but aside from an up vote, not much happened.
Could someone take a look, and see what I'm doing wrong? Because I did fall all the on-line tutorials, I queried in all the different way people do it, and still nothing :( To help you understand what I'm doing this are some examples:
The command that I'm using is:
dtrace -n 'profile-97/execname == "node" && arg1/{@[jstack(150, 8000)] = count(); } tick-60s { exit(0); }' > stacks.out
The output that I get is:
CPU ID FUNCTION:NAME 0 312432 :tick-30s
If I do dtrace -l then I get for example:
58814 instr kernel setup_APIC_eilvt-jne 0xffffffff81045e27 58815 instr kernel setup_APIC_eilvt-je 0xffffffff81045e34 58816 instr kernel setup_APIC_eilvt-je 0xffffffff81045e38 58817 instr kernel setup_APIC_eilvt-callr 0xffffffff81045e46 58818 instr kernel setup_APIC_eilvt-callr 0xffffffff81045e6a 58819 instr kernel lapic_timer_setup.part.4-cli 0xffffffff81045ea0 58820 instr kernel lapic_timer_setup.part.4-jbe 0xffffffff81045eaa 58821 instr kernel lapic_timer_setup.part.4-jbe 0xffffffff81045eaf 58822 instr kernel lapic_timer_setup.part.4-callr 0xffffffff81045ed4 58823 instr kernel lapic_timer_setup-je 0xffffffff81045f39 58824 instr kernel lapic_timer_setup-repz 0xffffffff81045f3b 58825 instr kernel local_apic_timer_interrupt-je 0xffffffff81045f74 58826 instr kernel local_apic_timer_interrupt-callr 0xffffffff81045f90 58827 instr kernel local_apic_timer_interrupt-je 0xffffffff81045f99 58828 instr kernel clear_local_APIC-jne 0xffffffff8104610e 58829 instr kernel clear_local_APIC-jg 0xffffffff810461c3 58830 instr kernel clear_local_APIC-je 0xffffffff8104629a 58831 instr kernel disable_local_APIC-jne 0xffffffff810463bd 58832 instr kernel disable_local_APIC-je 0xffffffff810463c7 58833 instr kernel disable_local_APIC-callr 0xffffffff810463c9 58834 instr kernel disable_local_APIC-repz 0xffffffff81046400 58835 instr kernel lapic_suspend-jne 0xffffffff8104641d 58836 instr kernel lapic_suspend-jg 0xffffffff81046555 58837 instr kernel lapic_suspend-cli 0xffffffff81046561 58838 instr kernel lapic_suspend-callr 0xffffffff81046568
And if I list all the processes that open files with:
dtrace -q -n syscall::open:entry'{ printf("%-16s%-16s\n", execname,copyinstr(arg0)); }'
I get all the processes opening files, it even show NodeJS starting and getting ready for work :)
vminfo /var/run/utmp vminfo /var/run/utmp systemd /proc/145/cgroup vminfo /var/run/utmp vminfo /var/run/utmp vminfo /var/run/utmp vminfo /var/run/utmp systemd /proc/460/cgroup vminfo /var/run/utmp vminfo /var/run/utmp node /etc/ld.so.cache node /lib/x86_64-linux-gnu/libdl.so.2 node /lib/x86_64-linux-gnu/librt.so.1 node /usr/lib/x86_64-linux-gnu/libstdc++.so.6 node /lib/x86_64-linux-gnu/libm.so.6 node /lib/x86_64-linux-gnu/libgcc_s.so.1 node /lib/x86_64-linux-gnu/libpthread.so.0 node /lib/x86_64-linux-gnu/libc.so.6 node /dev/urandom node /home/davidgatti/test/ble.js node /etc/resolv.conf node /etc/nsswitch.conf node /dev/urandom node /dev/pts/0 node /dev/null node /dev/pts/0 vminfo /var/run/utmp vminfo /var/run/utmp systemd /proc/145/cgroup
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dtrace4linux/linux/issues/128, or mute the thread https://github.com/notifications/unsubscribe-auth/ABWFhF5uPG3IShMoHBSb-GG-qde5i249ks5rHAn6gaJpZM4LJ8C4 .
@dtrace4linux I'm bit confused :O is this the same dtrace that people are mentioning in this article for example?
no idea. they may be referring to macos/dtrace.
On 14 December 2016 at 17:45, David Gatti notifications@github.com wrote:
@dtrace4linux https://github.com/dtrace4linux I'm bit confused :O is this the same dtrace that people are mentioning in this article for example?
https://nodejs.org/en/blog/uncategorized/profiling-node-js/
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dtrace4linux/linux/issues/128#issuecomment-267102667, or mute the thread https://github.com/notifications/unsubscribe-auth/ABWFhOr188rrjrmYXC11AFPDShs1q575ks5rICszgaJpZM4LJ8C4 .
@dtrace4linux If you had an extra moment could you explain why that would be different? Because my understanding for now is that dtrace is used to analyze what a specific process is doing.
No irony or tiredness on my part, I would like to just understand better.
there are about 4 implementations in the world. The original was from Sun for Solaris (now Oracle). A port was done to freebsd. Apple ported it to MacOS and made it work properly with the OS. I ported it (original Sun) to Linux. Dtrace is effectively a "hook" at the kernel level - intercepting all interrupts and system calls, and consists of a kernel module, but also, a user-space component (used for tracing user land function/system calls). I got only so far in getting Linux to work for user mode probes. To work properly has required:
The code from solaris was mostly impenetrable. Even "strace" on linux evolved to accomodate the broken and now much better "signal" model in the kernel, with much breakage in how syscall tracing works.
Add to the above, the 32b and 64b kernels, and very frequently changing syscall sequences.
Add to this the license debate, and how systemtap/ftrace gets the love and attention - dtrace is a second class citizen. It is stuck in a world of politics, inconsistent licensing and dubious levels of ownership.
As an open source product, I put in small amounts of effort variously, but the diversity of linux distros, changing kernel versions, means its not practical to keep it running across the almost weekly kernel releases. Not without serious funding, which is unlikely to ever happen or is warranted.
I have a few little fixes for dtrace for later kernels, but the user land portion requires significant work to make it provably reliable.
On 14 December 2016 at 23:51, David Gatti notifications@github.com wrote:
@dtrace4linux https://github.com/dtrace4linux If you had an extra moment could you explain why that would be different? Because my understanding for now is that dtrace is used to analyze what a specific process is doing.
No irony or tiredness on my part, I would like to just understand better.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dtrace4linux/linux/issues/128#issuecomment-267193596, or mute the thread https://github.com/notifications/unsubscribe-auth/ABWFhOhSVtOqVOGQQAxjoL5HuqO80tb8ks5rIIEJgaJpZM4LJ8C4 .
@dtrace4linux super cool, thank you for your explanation, that is a very nice insight on what is going on.
Going back to the article that I linked (https://nodejs.org/en/blog/uncategorized/profiling-node-js/), there is this statement
You can absolutely profile apps in production, not just development, since compiling with DTrace support has very minimal overhead. You can start and stop profiling without restarting your program.
My assumption would be that they are talking about linux, nobody will run a server on macOS (maybe FreeBSD?)
In the article at the end there is also a link that I missed to http://dtrace.org/blogs/about/, where in the about section there is this statement
A Linux port is in development.
Which I'm assuming they are talking about your work, right?
The probability that there is another Linux port is basically 0, right?
Correct
On 20 Dec 2016 14:32, "David Gatti" notifications@github.com wrote:
@dtrace4linux https://github.com/dtrace4linux super cool, thank you for your explanation, that is a very nice insight on what is going on.
Going back to the article that I linked (https://nodejs.org/en/blog/ uncategorized/profiling-node-js/), there is this statement
You can absolutely profile apps in production, not just development, since compiling with DTrace support has very minimal overhead. You can start and stop profiling without restarting your program.
My assumption would be that they are talking about linux, nobody will run a server on macOS (maybe FreeBSD?)
In the article at the end there is also a link that I missed to http://dtrace.org/blogs/about/, where in the about section there is this statement
A Linux port is in development.
Which I'm assuming they are talking about your work, right? The point
The probability that there is another Linux port is basically 0, right?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dtrace4linux/linux/issues/128#issuecomment-268257227, or mute the thread https://github.com/notifications/unsubscribe-auth/ABWFhIU-sT3vd_1i6RVvMxt0R5_RXmeAks5rJ-bigaJpZM4LJ8C4 .
OK, cool. I think I'm smarter now thanks to you :) and I learned a little bit of history with this issue ;)
Thank you again.
You are my last hope ;) I'm having issue collecting some good data from NodeJS. I explained the problem on stackoverflow.com but aside from an up vote, not much happened.
Could someone take a look, and see what I'm doing wrong? Because I did fall all the on-line tutorials, I queried in all the different way people do it, and still nothing :( To help you understand what I'm doing this are some examples:
The command that I'm using is:
The output that I get is:
If I do
dtrace -l
then I get for example:And if I list all the processes that open files with:
I get all the processes opening files, it even show NodeJS starting and getting ready for work :)