Ezprofiler - provides a simple to use profiling mechanism to inspect the behavior of an application on a target VM

Hi,

One of my first Elixir apps. A simple to use profiling mechanism to inspect the behavior of an application on a target VM. Under the hood it utilizes Erlang’s profiler tools, namely eprof , the default, fprof or cprof . This runs as a stand-alone escript for both for ease of use and to minimize impact on the target VM. Controlled via a simple text console.

Two ways to profile:

processes

Attach the profiler to specific processes, registered names or pg/pg2 groups, or a list of any of those. When profiling starts those processes will be traced.

code
The process option can be omitted. Instead the code can be decorated with profiling start/stop functions. In this case, to simplify the analysis, only a single (the first) process to git that code block will be monitored. This is useful in, for example, web-based applications where 100’s of processes maybe spawned and invoke the same code at the same time. Can be safely attached to a production system.


$ ./ezprofiler --node myapp@localhost --processes :my_reg_pid --sos --mf "_:_"

Options:

     's' to start profiling when 'waiting'
     'a' to get profiling results when 'profiling'
     'r' to abandon (reset) profiling and go back to 'waiting' state with initial value for 'u' set
     'c' to enable code profiling (once)
     'c' "label"to enable code profiling (once) for label (an atom), e.g. "c special_atom"
     'u' "M:F" to update the module and function to trace (only with eprof)
     'v' to view last saved results file
     'g' for debugging, returns the state on the target VM
     'h' this help text
     'q' to exit

waiting..(1)>

Includes filters and support for the ranch framework.


ezprofiler --help

ezprofiler:

 --node [node]: the Erlang VM you want tracing on (e.g. myapp@localhost)

 --cookie [cookie]: the VM cookie (optional)

 --processes [pid or reg_name]: the remote process pid (e.g. "<0.249.0>") or registered name you want to trace (other options ranch or pg/pg2 group)

 --sos: if present will apply tracing to any process spawned by the one defined in --process

 --mf [string]: a specification of module:fun of which module and functions to trace, with underscore _ as a wildcard.
              Example "Foo:bar" will trace calls to Foo:bar "Foo:_" will trace calls to all functions in module Foo (default is "_:_")

 --directory: where to store the results
 
 --maxtime: the maximum time we allow profiling for (default 60 seconds)

 --profiler: one of eprof, cprof or fprof, default eprof

 --sort: for eprof one of time, calls, mfa (default time), for fprof one of acc or own (default acc). Nothing for cprof

 --help: this page

4 Likes

New version:

Fixed issue where code profiling included extra methods that should not be profiled
Allow functions with a 0 arity
Tidied documentation
Added --cpfo option