strace и perf для устранения неполадок в Linux

Когда сервер Linux работает медленно, вылетает или перегружает процессор, а журналы приложений не объясняют причину, два инструмента помогают устранить большинство неполадок. strace показывает, что именно процесс запрашивает у ядра. perf показывает, на что уходит время процессора. Вместе они отвечают на вопросы «почему система зависла» и «что она делает», с которыми ничто другое не справляется так просто.

В этой статье рассказывается, когда следует использовать каждый из этих инструментов, как их установить, какие команды вам понадобятся на практике и как свести к минимуму нагрузку на рабочий сервер.

Когда использовать strace, а когда perf

Отличие простое. Используйте perf , когда процессор загружен, и вам нужно узнать, какая функция за это отвечает. Используйте strace , когда процесс зависает, вылетает, возвращает странные ошибки или ведет себя так, как не объясняют логи.

perf производит выборку данных из аппаратных счетчиков ядра с настраиваемой частотой, поэтому накладные расходы обычно составляют менее 1%, и его можно безопасно запускать в производственной среде. strace перехватывает каждый системный вызов через ptrace, что может замедлить целевой процесс в 10–100 раз. Используйте его в рабочих системах с осторожностью и всегда с фильтрами.

Установка strace и perf

Оба инструмента находятся в стандартных репозиториях. strace использует ptrace syscall, который уже много лет входит в состав каждого современного ядра. perf использует perf_events интерфейс и требует пакета, соответствующего вашему ядру.

В Ubuntu или Debian:

sudo apt install strace linux-tools-common linux-tools-$(uname -r)

В RHEL, AlmaLinux или Fedora:

sudo dnf install strace perf

Бит $(uname -r) значение имеет разрядность. Бинарник perf, скомпилированный под другую версию ядра, выдает запутанный вывод и может незаметно пропускать события. Проверьте с помощью perf --version и strace -V после установки.

Чтобы perf отображал имена функций вместо шестнадцатеричных адресов, вам нужны отладочные символы. Установите соответствующий -dbg или -debuginfo (например, libc6-dbg в Debian) и скомпилируйте собственные бинарники с помощью -g в GCC.

Внутри контейнеров strace требуется --cap-add=SYS_PTRACE и perf необходимо --cap-add=SYS_ADMIN при запуске с помощью Docker. Без этих ограничений инструменты выходят из строя, что выглядит как ошибки.

Отслеживание системных вызовов с помощью strace

Запуск strace command trace отслеживает процесс с момента запуска. Чтобы присоединиться к запущенному процессу, используйте strace -p PID. Для любых многопоточных процессов или тех, которые создают дочерние процессы, добавьте -f для отслеживания дочерних процессов, иначе вы пропустите большую часть активности.

Строки вывода заканчиваются возвращаемым значением. -1 ENOENT означает, что файла, запрошенного процессом, нет. -1 EACCES означает проблемы с правами доступа. Эти две ошибки сами по себе составляют удивительно большую долю производственных ошибок.

Самый полезный флаг — -e trace=GROUP, который ограничивает вывод результатов по указанной категории системных вызовов и позволяет контролировать объем информации.

На загруженном сервере начните с strace -c -p PID на десять или двадцать секунд. Флаг -c флаг выводит сводку количества системных вызовов, общего времени и ошибок при отсоединении. Это позволяет определить, на какую категорию стоит обратить особое внимание, не перегружая терминал. Затем подключитесь снова с узким фильтром.

Другие флаги, о которых стоит знать: -T регистрирует время, затраченное на каждый вызов, -Z показывает только неудачные вызовы, и -o file записывает в лог вместо терминала, что работает намного быстрее при загруженном процессе.

Профилирование ЦП с помощью perf

В perf есть четыре команды, которые вы будете использовать чаще всего.

Начните с perf stat -p PID для быстрого обзора. Цифры, на которые следует обратить внимание:

• IPC (количество инструкций за такт) ниже 1,0: ЦП задерживается, обычно при доступе к памяти.
• Высокое количество промахов при загрузке LLC: рабочий набор не помещается в кэш, поэтому процессор ожидает ответа от ОЗУ.
• Высокое количество переключений контекста: классический признак для рабочих нагрузок, ограниченных вводом-выводом, где потоки постоянно блокируются на диске или в сети.

Если что-то выглядит не так, проверьте perf record -F 99 -g -p PID -- sleep 30. -F 99 выполняет выборку с частотой 99 Гц, чего достаточно для поиска «горячих» функций и позволяет избежать синхронизации с таймером ядра при круглых значениях, таких как 100 Гц. Флаг -g Флаг фиксирует графы вызовов, поэтому perf report может показать, какие пути входа в функцию являются виновными.

В perf reportстолбце «Накладные расходы» указана доля от общего числа выборок. Высокие накладные расходы в _int_malloc или memcpy означает интенсивное выделение памяти. Высокие накладные расходы в одной из ваших собственных функций — это и есть тот «горячий» участок, который вы искали.

Если вместо имен функций вы видите шестнадцатеричные адреса, это означает, что бинарный файл очищен или отсутствуют отладочные символы. Установите соответствующий -dbg пакет или пересоберите бинарник с -g.

Практический рабочий процесс на действующем сервере

В случае реального инцидента на загруженном сервере процедура выглядит следующим образом:

1. Сначала подтвердите симптом с помощью простых инструментов: top, vmstat, iostat. Если вы работаете на виртуальной машине, проверьте столбец st столбец (steal). Любое значение выше 5% означает, что узким местом является гипервизор, а не ваш код.
2. Если загрузка ЦП высокая, запустите perf top на несколько секунд, а затем perf record -F 99 -g -p PID -- sleep 30 для проблемного процесса. 30-секундный захват при частоте 99 Гц дает около 1,7 МБ данных.
3. Если процесс завис, работает медленно или возвращает ошибки, запустите strace -c -p PID в течение десяти секунд и прочитайте сводку. Если доминирует одна категория системных вызовов, сузьте поиск с помощью strace -e trace=GROUP -T -p PID.
4. Когда вы найдете подозрительный системный вызов или функцию, отсоединитесь. Не оставляйте ни один из инструментов работающим в производственной среде дольше, чем это необходимо.

Два предостережения. strace Вывод может содержать переменные среды, пути к файлам и байты, прочитанные из сокетов, поэтому очищайте журналы перед передачей их за пределы вашей команды. А если вы собираетесь делать это регулярно, в качестве следующего шага обратите внимание на bpftrace и более широкий набор инструментов eBPF в качестве следующего шага: такая же видимость, накладные расходы менее 1%, созданный для производственной среды с самого начала.

Если вы выполняете рабочие нагрузки, где важен глубокий диагностический доступ, а совместное использование инфраструктуры не является вариантом, ознакомьтесь с нашими выделенными серверами.