profile_<timestamp>.col
) and a flamegraph file (profile_<timestamp>.html
). Two symbolic links (last_profile.col
and last_flamegraph.html
) always point to the last output files.--output-dir
/-o
option to specify the output directory.--rotating-output
is given, only the last results are kept (available via last_profle.col
and last_flamegraph.html
). This can be used to avoid increasing gProfiler's disk usage over time. Useful in conjunction with --upload-results
(explained ahead) - historical results are available in the Granulate Performance Studio, and the very latest results are available locally.--no-flamegraph
can be given to avoid generation of the profile_<timestamp>.html
file - only the collapsed stack samples file will be created.--upload-results
/-u
flag. Pass the --token
option to specify the token provided by Granulate Performance Studio, and the --service-name
option to specify an identifier for the collected profiles, as will be viewed in the Granulate Performance Studio. Profiles sent from numerous gProfilers using the same service name will be aggregated together.--profiling-frequency
: The sampling frequency of the profiling, in hertz.--profiling-duration
: The duration of the each profiling session, in seconds.--no-java
or --java-mode disabled
: Disable profilers for Java.--no-java-async-profiler-buildids
: Disable embedding of buildid+offset in async-profiler native frames (used when debug symbols are unavailable).--no-python
: Alias of --python-mode disabled
.--python-mode
: Controls which profiler is used for Python.auto
- (default) try with PyPerf (eBPF), fall back to py-spy.pyperf
- Use PyPerf with no py-spy fallback.pyspy
- Use py-spy.disabled
- Disable profilers for Python.--no-php
or --php-mode disabled
: Disable profilers for PHP.--php-proc-filter
: Process filter (pgrep
) to select PHP processes for profiling (this is phpspy's -P
option)--no-ruby
or --ruby-mode disabled
: Disable profilers for Ruby.--nodejs-mode
: Controls which profiler is used for NodeJS.none
- (default) no profiler is used.perf
- augment the system profiler (perf
) results with jitdump files generated by NodeJS. This requires running your node
processes with --perf-prof
(and for Node >= 10, with --interpreted-frames-native-stack
). See this NodeJS page for more information.--perf-mode
: Controls the global perf strategy. Must be one of the following options:fp
- Use Frame Pointers for the call graphdwarf
- Use DWARF for the call graph (adds the --call-graph dwarf
argument to the perf
command)smart
- Run both fp
and dwarf
, then choose the result with the highest average of stack frames count, per process.--upload-results
/-u
flag) This behavior can be disabled by passing --dont-send-logs
or the setting environment variable GPROFILER_DONT_SEND_LOGS=1
.--upload-results
/-u
flag is not set. Otherwise, you can disable metrics and metadata by using the following parameters:--disable-metrics-collection
to disable metrics collection--disable-metadata-collection
to disable metadata collection--continuous
/-c
flag. Note that when using --continuous
with --output-dir
, a new file will be created during each sampling interval. Aggregations are only available when uploading to the Granulate Performance Studio./lib/modules/$(uname -r)/build
. On Ubuntu, this directory is a symlink pointing to /usr/src
. The command above mounts both of these directories./tmp
by default; if your /tmp
is marked with noexec
, you can add TMPDIR=/proc/self/cwd
to have everything unpacked in your current working directory.GPROFILER_TOKEN
and GPROFILER_SERVICE
variables in the appropriate location!Next Step
<TOKEN>
in the command line with your token you got from the gProfiler Performance Studio site<SERVICE NAME>
in the command line with the service name you wish to useSave
Create
Services
, and choose Create
EC2
launch type and the granulate-gprofiler
task definition with the latest revisionDAEMON
service typeNext step
until you reach the Review
page, and then click Create Service
"pidMode": "host"
in the task definition (see documentation of pidMode
here). Host PID is required for gProfiler to be able to profile processes running in other containers (in case of Fargate, other containers under the same containerDefinition
).command
parameter of your entry in the containerDefinitions
array. The new command should include downloading of gProfiler & executing it in the background.command
is ["python", "/path/to/my/app.py"]
, we will now change it to: "bash", "-c", "(wget -q https://github.com/Granulate/gprofiler/releases/latest/download/gprofiler -O /tmp/gprofiler; chmod +x /tmp/gprofiler; /tmp/gprofiler -cu --token <TOKEN> --service-name <SERVICE NAME> --disable-pidns-check --perf-mode none) > /tmp/gprofiler_log 2>&1 & python /path/to/my/app.py"
. This new command will start the downloading of gProfiler in the background, then run your application.--disable-pidns-check
is required because, well, we won't run in init PID NS :)--perf-mode none
is required because our container will not have permissions to run system-wide perf
, so gProfiler will profile only runtime processes. See perf-less mode for more information.wget
installed - you can make sure wget
is installed, or substitute it with curl
or any other HTTP-downloader you wish.linuxParameters
to the container definition (this goes directly in your entry in containerDefinitinos
):SYS_PTRACE
is required by various profilers, and Fargate by default denies it for containers.Dockerfile
to avoid having to download it every time in run-time. Then you just need to invoke it upon container start-up.docker-compose
by using the template file in docker-compose.yml. Start by replacing the <TOKEN>
and <SERVICE NAME>
with values in the command
section -<TOKEN>
should be replaced with your personal token from the gProfiler Performance Studio site (in the Install Service section)<SERVICE NAME>
should be replaced with whatever service name you wish to usecommand
section. For example, if you wish to use the py-spy
profiler, you could replace the command with -cu --token "<TOKEN>" --service-name "<SERVICE NAME>" --python-mode pyspy
.perf
in system wide mode, collecting profiling data for all running processes. Alongside perf
, gProfiler invokes runtime-specific profilers for processes based on these environments:--perf-prof
):perf inject --jit
and NodeJS's ability to generate jitdump files. See NodeJS profiling options.perf
which produces native stacks of the JVM / CPython interpreter. The runtime stacks are then merged into the data collected by perf
, substituting the native stacks perf
has collected for those processes.perf
- this is useful where perf
can't be used, for whatever reason (e.g permissions). This mode is enabled by --perf-mode disabled
.perf
). This means that, although the results from different profilers are viewed on the same graph, they are not necessarily of the same scale: so you can compare the samples count of Java to Java, but not Java to Python.__version__
in __init__.py
.__version__
update) and push it.--perf-mode smart
(which is the default). Read more about it in the Profiling options section↩