search

jvm-profiling-tools / honest-profiler

A sampling JVM profiler without the safepoint sample bias
https://github.com/RichardWarburton/honest-profiler/wiki
MIT License
1.25k stars 146 forks source link

report system and user cpu time #128

Open ceeaspb opened 8 years ago

ceeaspb commented 8 years ago

It depends on the workload, but as it currently stands a java process that is consuming a large proportion of its time on cpu in kernel might not be very visible in the reports.

Capturing and reporting the time split in user/system cpu may help indicate any significant time outside of java stack frames.

This could be complementary actually reporting native frames, see #127

nitsanw commented 8 years ago

AGCT should be able to climb out of native code back to the last Java frame. This doesn't always work. Supplementing the report with sampling of thread user/system CPU usage split is not that hard to do.

RichardWarburton commented 8 years ago

I do wonder whether its something we want to do. This is a profiler, if you want to understand CPU metrics breakdowns then a monitoring system is the right tool to solve that problem. Of course at the moment its quite hard to correlate information between HP and such a tool. Perhaps the thing that is required is to expose such information better? Perhaps a release to maven central with a proper exposed API would help?

On the other hand maybe everyone just uses it in isolated load test scenarios and in that case having such a view is useful.

ceeaspb commented 8 years ago

Rather than per frame or per second breakdowns, I was thinking of just a high level 1 line in the report for the whole profiling session : real x seconds, user y seconds, system z seconds.

nitsanw commented 8 years ago

I think a per thread user/system time for period sampled will be very informative. You can also take the process stats, but I'm thinking a per thread view is actually very useful. One of the pitfalls of profiling multi-threaded apps is the overall CPU stat often hides the fact some threads are starving others, and the hottest methods on the process level can in that case be poor indicators of the actual top bottlenecks.