Provided by: bpfcc-tools_0.18.0+ds-2_all bug


       ustat,  javastat,  nodestat,  perlstat,  phpstat, pythonstat, rubystat, tclstat - Activity
       stats from high-level languages.


       javastat  [-C]  [-S  {cload,excp,gc,method,objnew,thread}]  [-r  MAXROWS]  [-d]  [interval
       nodestat  [-C]  [-S  {cload,excp,gc,method,objnew,thread}]  [-r  MAXROWS]  [-d]  [interval
       perlstat  [-C]  [-S  {cload,excp,gc,method,objnew,thread}]  [-r  MAXROWS]  [-d]  [interval
       phpstat   [-C]  [-S  {cload,excp,gc,method,objnew,thread}]  [-r  MAXROWS]  [-d]  [interval
       pythonstat [-C] [-S  {cload,excp,gc,method,objnew,thread}]  [-r  MAXROWS]  [-d]  [interval
       rubystat  [-C]  [-S  {cload,excp,gc,method,objnew,thread}]  [-r  MAXROWS]  [-d]  [interval
       tclstat  [-C]  [-S  {cload,excp,gc,method,objnew,thread}]  [-r  MAXROWS]  [-d]   [interval
       ustat          [-l          {java,node,perl,php,python,ruby,tcl}]         [-C]         [-S
       {cload,excp,gc,method,objnew,thread}] [-r MAXROWS] [-d] [interval [count]]


       This is "top" for high-level language events, such  as  garbage  collections,  exceptions,
       thread  creations,  object  allocations, method calls, and more. The events are aggregated
       for each process and printed in a top-like table, which can be sorted by  various  fields.
       Not all language runtimes provide the same set of details.

       This uses in-kernel eBPF maps to store per process summaries for efficiency.

       This tool relies on USDT probes embedded in many high-level languages, such as Java, Node,
       Perl, PHP, Python, Ruby, and Tcl. It requires a runtime instrumented  with  these  probes,
       which  in  some  cases  requires  building  from source with a USDT-specific flag, such as
       "--enable-dtrace" or "--with-dtrace". For Java, some probes are not  enabled  by  default,
       and  can  be  turned  on  by running the Java process with the "-XX:+ExtendedDTraceProbes"
       flag. For PHP processes, the environment variable USE_ZEND_DTRACE must be set to 1.

       Newly-created processes will only be traced at the next interval. If  you  run  this  tool
       with  a  short  interval  (say,  1-5  seconds), this should be virtually unnoticeable. For
       longer intervals, you might miss processes that were started  and  terminated  during  the
       interval window.

       Since this uses BPF, only the root user can use this tool.


       CONFIG_BPF and bcc.


       -l {java,node,perl,php,python,ruby,tcl}
              The language to trace. By default, all languages are traced.

       -C     Do not clear the screen between updates.

       -S {cload,excp,gc,method,objnew,thread}
              Sort the output by the specified field.

       -r MAXROWS
              Do not print more than this number of rows.

       -d     Print the resulting BPF program, for debugging purposes.

              Interval between updates, seconds.

       count  Number of interval summaries.


       Summarize activity in high-level languages, 1 second refresh:
              # ustat

       Don't clear the screen, and top 8 rows only:
              # ustat -Cr 8

       5 second summaries, 10 times only:
              # ustat 5 10


              The contents of /proc/loadavg

       PID    Process ID.

              Process command line (often the second and following arguments will give you a hint
              as to which application is being run.

              Count of method invocations during interval.

       GC/s   Count of garbage collections during interval.

              Count of objects allocated during interval.

              Count of classes loaded during interval.

       EXC/s  Count of exceptions thrown during interval.

       THR/s  Count of threads created during interval.


       When using this tool with high-frequency events, such as method calls, a very  significant
       slow-down  can be expected. However, many of the high-level languages covered by this tool
       already have a  fairly  high  per-method  invocation  cost,  especially  when  running  in
       interpreted  mode.  For  the lower-frequency events, such as garbage collections or thread
       creations, the overhead  should  not  be  significant.  Specifically,  when  probing  Java
       processes  and  not  using the "-XX:+ExtendedDTraceProbes" flag, the most expensive probes
       are not emitted, and the overhead should be acceptable.


       This is from bcc.


       Also look in the bcc distribution for a companion  _example.txt  file  containing  example
       usage, output, and commentary for this tool.




       Unstable - in development.


       Sasha Goldshtein


       trace(8), argdist(8), tplist(8)