rbspy VS bcc

Even the most general profiler tool will show you each statement's accumulated time. These are called statistical profilers and give you a panoramic view of what the test is doing. An example of such a profiler is rbspy:

As a result, you need to craft a specific routine for each interpreter runtime (in some cases, each version of that runtime) to obtain symbol information. Educated eyes might have already noticed, it's not an easy undertaking considering the sheer amount of interpreted languages out there. For example, a very well known Ruby profiler, rbspy, generates code for reading internal structs of the Ruby runtime for each version.

I was a bit surprised to find out that the tool used to generate the flamegraph for Ruby (rbspy [1]) is written in Rust. lol

[1] https://github.com/rbspy/rbspy

c function is not very helpful to find the performance problem, so we dug deeper.

On Linux, this can be done using BPF (Berkley Packet Filter). In fact there is a tool in BCC[0] called filetop, which lists reads/writes by process and file[1].

0. https://github.com/iovisor/bcc

1. https://github.com/iovisor/bcc/blob/master/tools/filetop.py

I recommend you investigate using eBPF hooks in the linux kernel for this allocation tracking, it is measurable much faster. E.g. https://github.com/iovisor/bcc/blob/master/tools/memleak.py

Hey there! Of course. There are a few good examples here and here. Yes, they're specific tools (which I, by the way, do recommend), but you can have a look at the BPF code here as well.

Thanks for the link :) this one seems pretty much like what I was looking for, with Vxlan encapsulation, will bother you if i face issues on running the script they have there. Looks like couple of years old since the last contribution to that git page: https://github.com/iovisor/bcc/tree/master/examples/networking/tunnel_monitor

What we saw was stalling in the kernel run queue. One of the other people on our team did some debugging with eBPF. I think they may have used runqlen.py. But as soon as they evicted the one damaging pod from the machine, all the other workloads were no longer starved.

We set out to look for an additional probe that can help us complete the picture. Even then, we find eBPF useful to explore the linux TCP stack. Tools like stacksnoop or stackcount can be used to understand the flow a network packet is going through when it’s processed and compare different functions to see how “noisy” each function is. Searching for data probing locations consists of a constant trade-off between being too nosy and being blind, and we’re looking for the sweet spot in the middle.

If you're interested specifically in bash, you can look into bcc's bashreadline to output user commands. If you're interested in applying security policies to potential user commands, you can also take a look at Tracee although other open source solutions exist here as well.

That's right! There's no "traditional" loops as programs have to be proved to terminate at some point.

That being said, very recently support for bounded loops landed [0]. It's very exciting and useful, and I've seen it reduce verification times significantly, but we can't use this yet as it requires kernel 5.3 or greater, and we would like to support as many users as possible!

[0]: https://lwn.net/Articles/877062/

[1]: https://github.com/iovisor/bcc/commit/38304256c49a02aecbf78f...