about:performance: “Профилируя процессы в Linux хорошо бы представлять оверхед от инструме…”

Профилируя процессы в Linux хорошо бы представлять оверхед от инструментов и выбирать подходящий под задачу.

На примере работы утилиты dd сравним накладные расходы strace, perf и bpftrace (eBPF).

Для начала запустим dd без оберток:

# dd if=/dev/zero of=/dev/null bs=512 count=100k
102400+0 records in
102400+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.0229283 s, 2.3 GB/s

Скорость в 2.3GB/s будет эталонной, с которой и будем все сравнивать.

strace

# strace -c dd if=/dev/zero of=/dev/null bs=512 count=100k
102400+0 records in
102400+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 1.73851 s, 30.2 MB/s
...

Падение скорости в ~76 раз, неплохо поработали!

perf

# perf stat -e 'syscalls:sys_enter_*' dd if=/dev/zero of=/dev/null bs=512 count=100k
102400+0 records in
102400+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.0287921 s, 1.8 GB/s

Замедление на треть уже и не выглядит чем-то страшным:)

bpftrace

# bpftrace -e 'tracepoint:syscalls:sys_enter_* /comm == "dd"/
{ @[probe] = count(); }'  -c '/usr/bin/dd if=/dev/zero of=/dev/null bs=512 count=100k'
102400+0 records in
102400+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.0475401 s, 1.1 GB/s

Хваленный eBPF дал оверхеда более чем в 2 раза! А говорили, что "eBPF это про скорость" :(

——————————————————

С strace всё ясно: он через ptrace приостанавливает dd на каждом syscall, с переходом в kernel mode и обратно.

Но в чем eBPF не справился? Давайте обсудим!

Важно помнить: dd генерирует много системных вызовов, поэтому такой большой оверхед у `strace`. Цифры выше это скорее утрированный пример, но суть отражают верно.