syscount.bt(8)

💖 syscount.bt — the manual, but make it make sense 💖

okay bestie, welcome to syscount.bt(8) from the System Manager's Manual — yes she's a real section-8 girly and she counts syscalls for a living 💅

---

✨ NAME ✨

syscount.bt — counts system calls. uses bpftrace/eBPF. no cap.

---

🌸 SYNOPSIS 🌸

syscount.bt -- [--sysname]

---

🦋 DESCRIPTION 🦋

so basically this counts system calls (syscalls, the little guys 🐣) and prints a summary of the top ten syscall IDs plus the top ten process names that are out here making syscalls. this is lowkey so useful for characterizing your kernel and resource workload, and for finding the applications that are using syscalls inefficiently (we're side-eyeing them 🙈).

the way it works is by using the tracepoint:raw_syscalls:sys_enter tracepoint. that's the whole trick, iconic honestly.

since this uses BPF, only the root user can use this tool. not a vibe if you're logged in as anyone else, sorry bestie 😭

---

🎀 OPTIONS 🎀

• --sysname — show the syscall name instead of the syscall number. glow-up for your output, fr fr ✨

---

🫶 REQUIREMENTS 🫶

• CONFIG_BPF
• bpftrace

that's it. that's the list. periodt.

---

🌈 EXAMPLES 🌈

count system calls until you hit Ctrl-C:

# syscount.bt

---

👑 OUTPUT 👑

Top 10 syscalls IDs:

this shows the syscall ID number (in @syscall[]) followed by a count for this syscall during tracing. syscount.bt defaults to outputting the syscall number — that's her factory setting, she's not changing for anyone 💅

Top 10 syscalls NAMEs:

this shows the syscall ID name (in @syscallname[]) followed by a count for this syscall during tracing. use the --sysname parameter to output the system call name. yes you have to ask nicely.

Top 10 processes:

this shows the process name (in @process[]) followed by a count of syscalls during tracing. who's the main character of syscalls today? 👀

---

🔥 OVERHEAD 🔥

okay listen, this part matters so don't skim it.

for most applications, the overhead should be manageable if they perform 1000's or even 10,000's of syscalls per second. cute. but for higher rates, the overhead may become considerable — like, it's giving heavy. for example, tracing a microbenchmark loop of 4 million calls to geteuid() slows it down by 2.4x. 😭

but — and this is the important but — that represents tracing a workload that has a syscall rate of over 4 million syscalls per second per CPU, which should not be typical. in one large cloud production environment, rates of between 10k and 50k are typical, where the application overhead is expected to be closer to 1%. so like, chill.

for comparison, strace(1) in its current ptrace-based implementation (which it has had for decades, grandma is old) runs the same geteuid() workload 102x slower (that's one hundred and two times slower 💀). not me defending bpftrace but... yeah. 102x. read it and weep.

---

⭐ SOURCE ⭐

this is from bpftrace.

https://github.com/bpftrace/bpftrace

also look in the bpftrace distribution for a companion _examples.txt file containing example usage, output, and commentary for this tool. it's got the lore 📖

this is a bpftrace version of the bcc tool of the same name. the bcc version provides different command line options, and translates the syscall IDs to their syscall names. so don't come for me when the flags don't match, they're different girls 💅

https://github.com/iovisor/bcc

---

🧚 OS 🧚

Linux 🐧

---

💜 STABILITY 💜

Unstable — in development. she's still growing, be nice to her 🥺

---

🌸 AUTHOR 🌸

Brendan Gregg

---

💖 SEE ALSO 💖

• strace(1)

---

and that's the whole page bestie, thanks for coming to my TED talk 🫶 this little slice of the USER COMMANDS crew dropped on 2018-09-06 and she's still out here doing her syscount.bt(8) thing — go forth, count some syscalls, stay rooted 💅✨