not-perf

A sampling CPU profiler for Linux

  • 所有者: koute/not-perf
  • 平台:
  • 許可證: Apache License 2.0
  • 分類:
  • 主題:
  • 喜歡:
    0
      比較:

Github星跟蹤圖

Build Status

A sampling CPU profiler for Linux similar to perf

Features

  • Support for AMD64, ARM, AArch64 and MIPS64 architectures (where MIPS64 requires a tiny out-of-tree patch to the kernel to work)
  • Support for offline and online stack trace unwinding
  • Support for profiling of binaries without any debug info (without the .debug_frame section)
    • using .eh_frame based unwinding (this is how normal C++ exception handling unwinds the stack)
      without requiring .eh_frame_hdr (which, depending on the compiler, may not be emitted)
    • using .ARM.exidx + .ARM.extab based unwinding (which is ARM specific and is used instead of .eh_frame)
  • Support for cross-architectural data analysis
  • Fully architecture-agnostic data format
  • Built-in flamegraph generation

Why should I use this instead of perf?

If perf already works for you - great! Keep on using it.

This project was born out of a few limitations of the original perf
which make it non-ideal for CPU profiling in embedded-ish environments.
Some of those are as follows:

  • lack of support for MIPS64,
  • the big size of generated CPU profiling data due to offline-only stack unwinding,
    so if you only have a limited amount of storage space you either need to
    profile with a very low frequency, or for a very short amount of time;
  • lack of support for cross-architectural analysis - if you run perf record
    on ARM then you also need to run perf report either on ARM or under QEMU,
    and running the analysis under QEMU (depending on how you've compiled your binaries
    and with what flags you've launched perf) can take hours;
  • and poor support for profiling binaries which have limited or no debug info,
    which is often the case in big, embedded-lite projects where the debug info
    can't even fit on the target machine, or is not readily available.

Building

  1. Install at least Rust 1.31

  2. Build it:

     $ cd cli
     $ cargo build --release
    
  3. Grab the binary from target/release/.

Cross-compiling

  1. Configure the linker for your target architecture in your ~/.cargo/config, e.g.:
[target.mips64-unknown-linux-gnuabi64]
linker = "/path/to/your/sdk/mips64-octeon2-linux-gnu-gcc"
rustflags = [
  "-C", "link-arg=--sysroot=/path/to/your/sdk/sys-root/mips64-octeon2-linux-gnu"
]

[target.armv7-unknown-linux-gnueabihf]
linker = "/path/to/your/sdk/arm-cortexa15-linux-gnueabihf-gcc"
rustflags = [
  "-C", "link-arg=--sysroot=/path/to/your/sdk/sys-root/arm-cortexa15-linux-gnueabihf"
]
  1. Compile, either for ARM or for MIPS64:

     $ cargo build --release --target=mips64-unknown-linux-gnuabi64
     $ cargo build --release --target=armv7-unknown-linux-gnueabihf
    
  2. Grab the binary from target/mips64-unknown-linux-gnuabi64/ or target/armv7-unknown-linux-gnueabihf/.

Basic usage

Profiling an already running process by its PID:

$ cargo run record -p $PID_OF_YOUR_PROCESS -o datafile

Profiling a process by its name and waiting if it isn't running yet:

$ cargo run record -P cpu-hungry-program -w -o datafile

Generating a CPU flame graph from the gathered data:

$ cargo run flamegraph datafile > flame.svg

Replace cargo run with the path to the executable if you're running the profiler
outside of its build directory.

License

Licensed under either of

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you, as defined in the Apache-2.0 license, shall be
dual licensed as above, without any additional terms or conditions.

主要指標

概覽
名稱與所有者koute/not-perf
主編程語言Rust
編程語言Rust (語言數: 5)
平台
許可證Apache License 2.0
所有者活动
創建於2018-04-27 12:46:27
推送於2023-10-09 23:37:57
最后一次提交2023-03-24 08:28:48
發布數2
最新版本名稱0.1.1 (發布於 )
第一版名稱0.1.0 (發布於 )
用户参与
星數888
關注者數28
派生數43
提交數372
已啟用問題?
問題數30
打開的問題數19
拉請求數4
打開的拉請求數4
關閉的拉請求數2
项目设置
已啟用Wiki?
已存檔?
是復刻?
已鎖定?
是鏡像?
是私有?