Бывает приложение начинает тормозить из-за огромного количества файловых операций, хотя CPU и диск выглядят нормально
Например, процесс может тысячи раз в секунду проверять один и тот же отсутствующий файл, конфигурацию или каталог
opensnoop позволяет увидеть эти обращения непосредственно на уровне syscall open, openat и openat2 
Смотрим, кто открывает файлыopensnoop
В выводе будут PID, процесс, результат операции и путь
PID COMM FD ERR PATH
4217 app 12 0 /etc/app/config.json
4217 app -1 2 /etc/app/cache.db
4217 app -1 2 /tmp/app.lock
FD=-1 означает, что открыть файл не удалось, а ERR=2 соответствует ENOENT - файла не существует Почему ошибки открытия особенно интересныДопустим, приложение постоянно делает:
openat("/etc/app/cache.db") → ENOENT
openat("/etc/app/cache.db") → ENOENT
openat("/etc/app/cache.db") → ENOENTФайл отсутствует, поэтому I/O данных практически нет, но приложение продолжает выполнять системные вызовы и проходить путь поиска
BCC прямо отмечает такой сценарий как возможную причину проблем с производительностью.
Можно оставить только неудачные открытия:
opensnoop -x
Или ограничиться конкретным процессом:
opensnoop -p 4217
А если обращений слишком многоДля приложения, которое делает тысячи операций в секунду, вывод каждой строки сам становится неудобным.
Можно вместо этого агрегировать события через
bpftracebpftrace -e '
tracepoint:syscalls:sys_enter_openat
{
@[comm, str(args.filename)] = count();
}'
После остановки получим не тысячи одинаковых строк, а статистику
@[app, "/etc/app/config.json"]: 18432
@[app, "/tmp/app.lock"]: 9217
@[app, "/proc/self/status"]: 4081
bpftrace использует kernel tracepoint для openat() и позволяет собирать статистику непосредственно в ядре, а не просто печатать каждое событие Что искать в результатеОсобенно подозрительны огромные количества обращений к одному и тому же несуществующему файлу, постоянное чтение конфигурации вместо её кэширования, бесконечный поиск библиотек или конфигов по нескольким каталогам и приложения, которые постоянно открывают
/proc и /sysВажно и то, что
opensnoop показывает именно попытки открытия, а не только успешные операции - поэтому через него можно увидеть ошибки, которые обычный мониторинг диска вообще не заметит ⚡️Это хороший пример ситуации, когда проблема выглядит как «приложение просто тормозит», хотя причина находится намного ниже - в тысячах повторяющихся системных вызовов
openat() и неудачных поисках файлов
