Show HN: Xcapture-BPF – like Linux top, but with Xray vision

by tanelpoder • 2 years ago

447 39 2 years ago

jamesy0ung• 2 years ago

I’ve never used eBPF, does anyone have some good resources for learning it?

tanelpoder8• 2 years ago

Brendan Gregg's site (and book) is probably the best starting point (he was involved in DTrace work & rollout 20 years ago when at Sun) and was/is instrumental in pushing eBPF in Linux even further than DTrace ever went:

https://brendangregg.com/ebpf.html

bcantrill• 2 years ago

Just a quick clarification: while Brendan was certainly an active DTrace user and evangelist, he wasn't involved in the development of DTrace itself -- or its rollout. (Brendan came to Sun in 2006; DTrace was released in 2003.) As for eBPF with respect to DTrace, I would say that they are different systems with different goals and approaches rather than one eclipsing the other. (There are certainly many things that DTrace can do that eBPF/BCC cannot, some of the details of which we elaborated on in our 20th anniversary of DTrace's initial integration.[0])

Edit: We actually went into much more specific detail on eBPF/BCC in contrast to DTrace a few weeks after the 20th anniversary podcast.[1]

[0] https://www.youtube.com/watch?v=IeUFzBBRilM

[1] https://www.youtube.com/watch?v=mqvVmYhclAg#t=12m7s

mgaunard4• 2 years ago

It lets you hook into various points in the kernel; ultimately you need to learn how the Linux kernel is structured to make the most of it.

Unlike a module, it can only really read data, not modify data structures, so it's nice for things like tracing kernel events.

The XDP subsystem is particularly designed for you to apply filters to network data before it makes it to the network stack, but it still doesn't give you the same level of control or performance as DPDK, since you still need the data to go to the kernel.

tanelpoder8• 2 years ago

Yep (the 0x.tools author here). If you look into my code, you'll see that I'm not a good developer :-) But I have a decent understanding of Linux kernel flow and kernel/app interaction dynamics, thanks to many years of troubleshooting large (Oracle) database workloads. So I knew exactly what I wanted to measure and how, just had to learn the eBPF parts. That's why I picked BCC instead of libbpf as I was somewhat familiar with it already, but fully dynamic and "self-updating" libbpf loading approach is the goal for v3 (help appreciated!)

tptacek4• 2 years ago

XDP, in its intended configuration, passes pointers to packets still on the driver DMA rings (or whatever) directly to BPF code, which can modify packets and forward them to other devices, bypassing the kernel stack completely. You can XDP_PASS a packet if you'd like it to hit the kernel, creating an skbuff, and bouncing it through all the kernel's network stack code, but the idea is that you don't want to do that; if you do, just use TC BPF, which is equivalently powerful and more flexible.

frankjr• 2 years ago

There's a bunch of examples over at https://github.com/iovisor/bcc

rascul• 2 years ago

You might find some interesting stuff here

https://ebpf.io/

lathiat• 2 years ago

I'll toot my own horn here. But there are plenty of presentations about it, Brendan Gregg's are usually pretty great.

"bpftrace recipes: 5 real problems solved" - Trent Lloyd (Everything Open 2023) https://www.youtube.com/watch?v=ZDTfcrp9pJI

__turbobrew__3• 2 years ago

I use BCC tools weekly to debug production issues. Recently I found we were massively pressuring page caches due to having a large number of loopback devices with their own page cache. Enabling direct io on the loopback devices fixed the issue.

eBPF is really a superpower, it lets you do things which are incomprehensible if you don’t know about it.

tptacek4• 2 years ago

I'd love to hear more of this debugging story!

__turbobrew__3• 2 years ago

Containers are offered block storage by creating a loopback device with a backing file on the kubelet’s file system. We noticed that on some very heavily utilized nodes that iowait was using 60% of all the available cores on the node.

I first confirmed that nvme drives were healthy according to SMART, I then worked up the stack and used BCC tools to look at block io latency. Block io latency was quite low for the NVME drives (microseconds) but was hundreds of milliseconds for the loopback block devices.

This lead me to believe that something was wrong with the loopback devices and not the underlying NVMEs. I used cachestat/cachetop and found that the page cache miss rate was very high and that we were thrashing the page cache constantly paging in and out data. From there I inspected the loopback devices using losetup and found that direct io was disabled and the sector size of the loopback device did not match the sector size of the backing filesystem.

I modified the loopback devices to use the same sector size as the block size of the underlying file system and enabled direct io. Instantly, the majority of the page cache was freed, iowait went way down, and io throughout went way up.

Without BCC tools I would have never been able to figure this out.

Double caching loopback devices is quite the footgun.

Another interesting thing we hit is that our version of losetup would happily fail to enable direct io but still give you a loopback device, this has since been fixed: https://github.com/util-linux/util-linux/commit/d53346ed082d...

jyxent• 2 years ago

I've been learning BCC / bpftrace recently to debug a memory leak issue on a customer's system, and it has been super useful.

malkia2• 2 years ago

Relatively how expensive is to capture the callstack when doing sample profiling?

With Intel CET's tech there should be way to capture a shadow stack, that really just contains entry points, but wondering if that's going to be used...

tanelpoder8• 2 years ago

The on-cpu sample profiling is not a big deal for my use cases as I don't need the "perf" sampling to happen at 10kHz or anything (more like 10-1Hz, but always on).

But the sched_switch tracepoint is the hottest event, without stack sampling it's 200-500ns per event (on my Xeon 63xx CPUs), depending on what data is collected. I use #ifdefs to compile in only the fields that are actually used (smaller thread_state struct, fewer branches and instructions to decode & cache). Surprisingly when I collect kernel stack, the overhead jumps higher up compared to user stack (kstack goes from say 400ns to 3200ns, while ustack jumps to 2800ns per event or so).

I have done almost zero optimizations (and I figure using libbpf/BTF/CO-RE will help too). But I'm ok with these numbers for most of my workloads of interest, and since eBPF programs are not cast in stone, can do further reductions, like actually sampling stacks in the sched_switch probe on every 10th occurrence or something.

So in worst case, this full-visibility approach might not be usable as always-on instrumentation for some workloads (like some redis/memcached/mysql lookups doing 10M context switches/s on a big server), but even with such workloads, a temporary increase in instrumentation overhead might be ok, when there are known recurring problems to troubleshoot.

malkia2• 2 years ago

Awesome info!!! Thanks a lot!

metroholografix• 2 years ago

Folks who find this useful might also be interested in otel-profiling-agent [1] which Elastic recently opensourced and donated to OpenTelemetry. It's a low-overhead eBPF-based continuous profiler which, besides native code, can unwind stacks from other widely used runtimes (Hotspot, V8, Python, .NET, Ruby, Perl, PHP).

[1] https://github.com/elastic/otel-profiling-agent

3abiton• 2 years ago

I am trying to wrap my head around it, still unclear what it does l.

zikohh• 2 years ago

That's like most of Grafana's documentation

kbouck• 2 years ago

Grafana has one too called Beyla.

https://grafana.com/oss/beyla-ebpf/

omerhac• 2 years ago

Cool tool. I know some great guys who built a successful startup out of the observability and safe kernel sandboxing you can get with eBPF. Wonder if it could be a good basis to build an osx version of win-internals.

Show HN: Xcapture-BPF – like Linux top, but with Xray vision

Related Stories