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 відстежує процес від моменту запуску. Щоб підключитися до запущеного процесу, використовуйте 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%, створений для виробничого середовища з самого початку.

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