go-profiler-notes
fgprof
| go-profiler-notes | fgprof | |
|---|---|---|
| 14 | 3 | |
| 3,483 | 2,759 | |
| 0.4% | - | |
| 1.5 | 3.3 | |
| about 2 months ago | 2 months ago | |
| Jupyter Notebook | Go | |
| Creative Commons Attribution Share Alike 4.0 | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
go-profiler-notes
- The Busy Developer's Guide to Go Profiling, Tracing and Observability
-
Dwarf-Based Stack Walking Using eBPF
Thanks!
As @brancz mentioned, Delve uses DWARF unwind information to produce backtraces (they are stored in the .debug_frame section for Go).
You are right, Go enabled frame pointers for all architectures as of 1.17 [0]. This is enabled to allow profilers to work well, without having to use to techniques such as the one we describe in our post.
When it gets funny is that there's `gopclntab`, a 3rd option in Go to unwind stacks, used by `panic` and I believe other parts of the runtime. If you are interested in more details, Felix Geisendörfer's repo contains way more details [1]
[0]: https://go.dev/doc/go1.17
[1]: https://github.com/DataDog/go-profiler-notes/blob/main/stack...
- Resources to Learn Profiling and Benchmarking
- go-profiler-notes/README.md at main · DataDog/go-profiler-notes
- Fantastic Symbols and Where to Find Them - Part 1
-
Share your must-know Go development tips
this is a good read about pprof https://github.com/DataDog/go-profiler-notes/blob/main/guide/README.md
- The Busy Developers's Guide to Go Profiling, Tracing and Observability
fgprof
- Fgprof – The Full Go Profiler
-
Go profiler service in AWS
As for OP: I'm not aware of a similar offering by AWS itself. You could try https://pyroscope.io/ but I'd be hesitant to recommend it because it's based (well, copied my code without attribution/license, different story : p) on my fgprof project. Unfortunately that means it won't scale to applications with many goroutines and add O(N) stop-the-world pauses to your application 🙈.
-
Pyroscope — continuous profiling software to help you identify performance issues.
I agree the UI could use some work, but generally speaking CPU profiling is supported and does work. In fact, any HTTP endpoint that returns a valid pprof profile works, so even custom profiles are supported, such as fgprof.
What are some alternatives?
parca - Continuous profiling for analysis of CPU and memory usage, down to the line number and throughout time. Saving infrastructure cost, improving performance, and increasing reliability.
profefe - Continuous profiling for long-term postmortem analysis
parca-agent - eBPF based always-on profiler auto-discovering targets in Kubernetes and systemd, zero code changes or restarts needed!
tlog - Terminal I/O logger
goimpl.nvim - Generate stub for interface on a type
pyroscope - Continuous Profiling Platform. Debug performance issues down to a single line of code [Moved to: https://github.com/grafana/pyroscope]
gotests - Automatically generate Go test boilerplate from your source code.
wzprof - WebAssembly Profiler based on Wazero
nvim
perforator - Record "perf" performance metrics for individual functions/regions of an ELF binary.
collect - collect all pprof profiles with one command
tlog - Observability events system