Monitoring non-chrome processes and more

[bra...@opera.com]

Hi,

I've been using dmprof for a little while and I've some questions and comments.

I think it is great that there is a tool and active work on it since it is so hard to debug such a complicated multi process beast as chrome is with normal development tools, but I've not really been able to get as much information from it as I would have liked.

First stumble point for me was that it only works for chrome and not for content_shell, and most likely not for any other process either. It looks like it can gather data but not analyze it because it fails to extract stack traces. I tracked it down to the three identical regexps in src/tools/find_runtime_symbols/proc_maps.py that matches .so files or chrome but nothing else. There seems to be more to it though since fixing those didn't give me any stack traces anyway. Does anyone know what else has to be fixed or has successfully used dmprof on content_shell?

Second, there are texts about it not being designed to debug v8 because there are other tools for that. That is both true and false. Some part of v8 memory, the javascript objects, might be outside the scope for dmprof, but v8 also has other allocations that are now covered by nothing. Considering that v8 memory can be the majority of memory, I think it's valuable to form a better image of what v8 is doing. For that I tried to disable optimization for v8 (v8_optimized_debug in common.gypi) but unfortunately with that flag changed v8 refused to run at all. Has anyone successfully analyzed memory usage with stacks in v8?

Question: I have noticed that there is work on a web application visualizer. If that is the best visualizer, is there any information on how to deploy it?

Then I have a wish list:

* I would like to have a view that merges all processes (and synchronizes over time) so that total memory usage can be understood. This also requires figuring out shared memory and only count it once, which is a less than trivial thing (for instance, text blocks for system libraries are shared, who should be blamed?).

* I like massif_visualizer, it would be great to be able to use it with the dmprof data files.

Best regards

Daniel - developer/paper shuffler Opera Software

[Dai Mikurube]

Hi Daniel,

Thanks for using it and your comments.

On Mon, Oct 28, 2013 at 5:58 PM, <bra...@opera.com> wrote:

Hi,

I've been using dmprof for a little while and I've some questions and comments.

I think it is great that there is a tool and active work on it since it is so hard to debug such a complicated multi process beast as chrome is with normal development tools, but I've not really been able to get as much information from it as I would have liked.

First stumble point for me was that it only works for chrome and not for content_shell, and most likely not for any other process either. It looks like it can gather data but not analyze it because it fails to extract stack traces. I tracked it down to the three identical regexps in src/tools/find_runtime_symbols/proc_maps.py that matches .so files or chrome but nothing else. There seems to be more to it though since fixing those didn't give me any stack traces anyway. Does anyone know what else has to be fixed or has successfully used dmprof on content_shell?

Ah, your guess is correct. This filename matching came from old Chromium's pprof, but I'm actually not sure why the original pprof has this filename limitation. "chrome" was an ad-hoc fix. find_runtime_tools is a partial clone of pprof.

http://src.chromium.org/viewvc/chrome/trunk/src/third_party/tcmalloc/chromium/src/pprof?revision=126412#l4348

https://code.google.com/p/gperftools/source/browse/src/pprof#4347

Then, in my local "Linux" environment, changing the regexp collected symbols for content_shell. Could you try this patch?

https://codereview.chromium.org/50663002/

Second, there are texts about it not being designed to debug v8 because there are other tools for that. That is both true and false. Some part of v8 memory, the javascript objects, might be outside the scope for dmprof, but v8 also has other allocations that are now covered by nothing. Considering that v8 memory can be the majority of memory, I think it's valuable to form a better image of what v8 is doing. For that I tried to disable optimization for v8 (v8_optimized_debug in common.gypi) but unfortunately with that flag changed v8 refused to run at all. Has anyone successfully analyzed memory usage with stacks in v8?

Do you mean memory used by V8 out of JavaScript heaps? The dmprof profiler potentially can profile it if it has backtrace information, but I'm not sure if V8 still omits some frame pointers with profiling==1 and profiling_full_stack_frames=1. Asking V8 team might help.

Question: I have noticed that there is work on a web application visualizer. If that is the best visualizer, is there any information on how to deploy it?

We're still working on it.  Some documentation will hopefully be available soon...

Then I have a wish list:

* I would like to have a view that merges all processes (and synchronizes over time) so that total memory usage can be understood. This also requires figuring out shared memory and only count it once, which is a less than trivial thing (for instance, text blocks for system libraries are shared, who should be blamed?).

Dmprof dumps can have page frame numbers by some env options, so it's potentially possible. I also think it'd be helpful, but it needs more work...

* I like massif_visualizer, it would be great to be able to use it with the dmprof data files.

Ah, I haven't used it. Let me give it a try later. (And, I wonder if you could introduce its good points when you have time.)

Best regards

Daniel - developer/paper shuffler Opera Software

--
You received this message because you are subscribed to the Google Groups "dmprof" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dmprof+un...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/dmprof/119d8336-9263-4663-a376-e2b8c03212cc%40chromium.org.

--

Dai MIKURUBE

   dmik...@chromium.org

[WenSheng He]

1. web application visualizer

2. merge all processes, i.e., analyze chrome as a whole program

I also like these purpose. Any progress?