Profiling a running Java application in command line

The jvmtop application is a convenient tool for profiling from the commandline. No need to stop the jvm. Usage:

jvmtop.sh --profile <PID>

Will give you output like this which will be updating while the app runs:

  Profiling PID 24015: org.apache.catalina.startup.Bootstrap
  36.16% (    57.57s) hudson.model.AbstractBuild.calcChangeSet()
  30.36% (    48.33s) hudson.scm.SubversionChangeLogParser.parse()
   7.14% (    11.37s) org.kohsuke.stapler.jelly.JellyClassTearOff.parseScript()
  ...

The advantage is that it does not take the use of instrumentation. The classes of the to-be-profiled jvm will not be altered.

If you are looking for something more visual then have a look at jvm-mon which is based on jvmtop

Can you collect 10 or 20 stack samples with jstack? Then if Foo is a method, its overall time usage is the fraction of samples containing it. Its CPU usage is the fraction of those samples that don't terminate in I/O or a system call. Its "self time" is the fraction of samples in which it itself is the terminus.

I don't need anything pretty. I either run it under the IDE and collect them that way, or use something like jstack that snapshots the stack of a running app.

That's the random-pause technique.

Looks like the "built-in" way to profile a java app from the command line is to start it with profiling command line parameters, like this

$ java -Xrunhprof:cpu=samples,file=myprogram.hprof ...

Then examine the file "myprogram.hprof" with some GUI tool (or web server tool like jhat) or command line tool after the process exits (and the file is created at that time).

If you use the "QUIT" signal trick, mentioned https://stackoverflow.com/a/2344436/32453 then you can generate a file at will without exiting the JVM (it appears to append to the previous output file). Or wait until the process exits and it will generate the file.

This (built-in) profiler does a sample infrequently so typically low slowdown/impact overall.

ref: http://web.archive.org/web/20160623224137/https://thunderguy.com/semicolon/2004/04/18/profiling-a-java-program-easily/

You could also just do the "poor man's profiler" by collecting lots of jstacks and dumping them into ex: a flamegraph or some other analyzer/conglomerator...