Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Wachy – A UI for eBPF-based performance debugging (rubrikinc.github.io)
116 points by vivek-jain on March 26, 2022 | hide | past | favorite | 11 comments
eBPF is an amazing technology that allows safely running user-supplied functions at pretty much arbitrary probe points in a kernel/user space context. Much has been written about how amazing this feature is for kernel observability. But as someone who writes user space code, what I find even more amazing is the support for tracing arbitrary user space programs, with no code changes and low overhead.

However, doing in-depth analysis can get complicated and time-consuming. My goal with wachy was to make this debugging significantly easier/faster to use, by displaying traces in a TUI next to the source code and allowing for interactive drilldown analysis. If you get a chance, check out the start of the demo video since (AFAIK) it's quite unique and gives a much clearer idea than I can provide with just text.




> Wachy uses the magic of eBPF ...

eBPF may be magical, but because it's not readily usable, nobody uses its magical powers.

I haven't tried Wachy, yet, but the short demo video on the landing page shows the power of eBPF, and the ease-of-use of Wachy.

I think Wachy is what would truly make eBPF magical.

I'm working my way back into contributing to Postgres community, and this will come in handy to chase performance issues.

Great job on coming up with the idea, executing it, making a polished product, and a polished demo video!

Thank you for making Wachy!

Just a small piece of advice: You pronounce it almost like "Whacky" in your demo. I thought it would be pronounced as "Watch-e". Choosing a better name, without ambiguity on how to pronounce it, would reduce confusion when people mention it to each other, make it easier for people to search for it on the internet, and may also help in adoption. Think of a better name/spelling, but don't lose the focus on making the tool better.


Thanks! Fair point about the naming - as they say, there are only two hard things in computer science: cache invalidation and naming things (and off-by-one errors). My personal view is that everyone should be free to pronounce things as they like (e.g. gif) but I didn't realize the implications for sharing and adoption.


Very cool! Most of my bpftrace usage has been on the kernel side, but out of habit I often fall back to the debugger (or printf) in userland, which can seriously distort analysis of low latency functions, especially if polling or timers are involved.

I am going to try this out next week.


Can Wachy be used to trace kernel code as well? And would you need to do anything specific to get that to work? (How would Wachy find the kernel sources?)

I was thinking this would be pretty cool to use for debugging device drivers on embedded devices especially w.r.t latency.


I'm afraid that's not supported today. But it looks like kprobes do support offsets within a function, so it should be possible to get it to work. That does sound pretty cool, please open an issue for this if you're interested! It might be as simple as (effectively) s/uprobe/kprobe/g, in which case I can try to get that working.


Fantastic tool - a simple gui to make the magic happen - I'll now actually want to performace test my code! (until I see how slow it runs haha). Thanks for your work.


Awesome! Can it be used for Rust?


As jpgvm mentioned, yes Rust is a compiled language so it works well with eBPF!

The full picture is always a bit nuanced though so to expand on that: I have tried it cursorily with rust [using wachy to trace wachy :)] and it appears to work. The one issue I would say is that wachy is currently hardcoded to use C++ symbol demangling, so rust function names are not completely accurate (although it's surprisingly decent) - please open an issue if you want that fixed (or if you run into any other issues)! I decided it's better to get it out there and improve things that people actually use rather than fix all my TODOs (excuses for being lazy).

And with rust async, I haven't tried it myself but looked into the details some time back. Wachy works by simply looking at function entry/exit timestamps, but the rust aysnc impl is using futures + poll rather than saving and restoring stacks, so it's not gonna work. You can presumably trace the future's poll function, which may or may not be useful. Although, perhaps with some custom eBPF logic and examining the poll return value it could be made to work...


And now I’m so confused… /s missing or not missing?


My guess is no /s here. Rust has introduced a whole new batch of folks to native code that probably don't yet understand the blocks debugging and tracing are built on.

To answer the GP though, yes. This will work with Rust but you might have to check release mode settings to ensure its not stripping symbols etc.


This is awesome. Thank you!




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: