Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Sketch] OS-level tracing #54

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Conversation

eugeneia
Copy link
Contributor

@eugeneia eugeneia commented Jul 3, 2017

This is my working branch for exploring OS-level tracing capabilities. So far it includes:

  • USDT probe support for Linux (via SystemTap)

This adds a build dependency (SystemTap) on Linux systems, so it might make sense to put this behind a flag. IMHO the (build-only) dependency is worth its weight and USDT probes should be there by default. What this gives you is that you can attach to probes (these were already defined for use with DTrace on Darwin) of running CCL processes via BCC’s trace:

# trace -p 2570 \
      'u:ccl:egc__start "used %d, gen %d", arg1, arg2' \
      'u:ccl:egc__finish "freed %d, gen %d", arg1, arg2' \
      'u:ccl:gc__start "used %d", arg1' \
      'u:ccl:gc__finish "freed %d", arg1'
> PID    TID    COMM         FUNC             -
2570   3469   lx86cl64     egc__start       used 2097152, gen 0
2570   3469   lx86cl64     egc__finish      freed 1514896, gen 0
2570   3484   lx86cl64     egc__start       used 2170256, gen 0
2570   3484   lx86cl64     egc__finish      freed 2065552, gen 0
2570   3499   lx86cl64     egc__start       used 2196624, gen 0
2570   3499   lx86cl64     egc__finish      freed 2090240, gen 0
2570   3514   lx86cl64     egc__start       used 2221312, gen 0
2570   3514   lx86cl64     egc__finish      freed 2116432, gen 0
...
2570   2571   lx86cl64     gc__start        used 55574528
2570   2571   lx86cl64     gc__finish       freed 32111648
2570   2571   lx86cl64     egc__start       used 2227232, gen 0
2570   2571   lx86cl64     egc__finish      freed 0, gen 0
...
  • PERF-HELPER, a mechanism to export symbol map files for use with Linux’s perf(1). The code/magic for this module was provided by Gary Byers, and worked out of the box, credit to him! In a nutshell it allows you to dump a map of the current heap:
(require "PERF-HELP")
(ccl:create-perf-map) ; will create "/tmp/perf-<PID>.map"

which allows perf(1) to reconstruct stack traces of a running CCL process. Now when you profile CCL via perf:

perf record -F 999 -p <PID> -g -- sleep 20 # Sample at 999 Hz for 20 seconds
perf report # labels stack frames using /tmp/perf-<PID>.map

Or instead of using perf report generate fancy SVG flame graphs, see http://www.brendangregg.com/flamegraphs.html :-)

If you look at the flame graph you can see that there are still a bunch of “unknown” frames. Some of these are kernel frames, and merely unresolved because I ran the example as a regular user, but some are indeed frames that point into the CCL process but can’t be resolved via the perf map. That’s a FIXME.

TODO

  • Add more USDT probes: there already exist probes for GC/EGC events as well as thread startup. There should be more events in CCL that make for interesting probes, suggestions welcome.

eugeneia added 4 commits July 2, 2017 16:57
This adds a module PERF-HELP that you can REQUIRE, it provides a function
CCL:CREATE-PERF-MAP to export a symbol map supported by OS level tracing
frameworks (for now only Linux x86).

On Linux, when the map is present (as a file in /tmp/perf-<pid>.map) perf(1)
will use it to reconstruct stack traces.

Ideas and code are mostly inherited from Gary Byers. Isn’t it great when you
set out to do something and find the hard parts already done? <3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant