B6. Профілювання

просунутийспирається на модуль 13, модуль 18

Мета

Остання робота курсу застосовує всі попередні модулі до одного практичного питання: чому це повільно?

Головна навичка тут навіть не в інструментах, а в порядку дій. Більшість людей одразу беруться за профілювальник і дивляться на функції. А починати слід із питання, чи програма взагалі рахує, чи вона просто чекає.

Потрібна ВМ, а не контейнер

perf потребує доступу до лічильників продуктивності процесора, а bpftrace — до трасувальних точок ядра. У непривілейованому контейнері немає ні того, ні того (модуль 17).

Порядок дій

Це головний матеріал роботи. Запам’ятайте послідовність — вона економить години.

1. Чи це взагалі процесор?

   top: якщо процес у стані S або D, а %wa високий — процесора вистачає, програма чекає. Профілювальник функцій тут не допоможе.

2. На чому саме чекає?

   strace -T -c покаже, у яких системних викликах минув час. Для стану D — cat /proc/<pid>/wchan або stack: там назва функції ядра, у якій процес заснув.

3. Якщо процесор — то де?

   perf top для живої картини, perf record + perf report для розбору. Дивитися спершу на частку, а не на назви.

4. Чи це взагалі обчислення?

   perf stat: відношення інструкцій до тактів (IPC). Менше одиниці — процесор чекає на пам’ять, а не рахує (модуль 2). Далі дивіться cache-misses і dTLB-load-misses (модуль 11).

5. Якщо потрібне те, чого немає в готових інструментах — bpftrace.

Завдання

Три задачі. У кожній треба знайти причину, довести її вимірюванням і виправити, а потім показати числа до і після.

1. Програма, що чекає.

   Візьміть або напишіть програму, яка читає файл дрібними порціями по 1 байту. Знайдіть це через strace -c, виправте буферизацією, покажіть різницю в кількості системних викликів і в часі (модуль 3).

2. Програма, що промахується повз кеш.

   Обхід двовимірного масиву за стовпцями замість рядків. Доведіть через perf stat, що справа в роботі з пам’яттю, а не в кількості операцій — кількість інструкцій має лишитися майже тією самою (модуль 2).

   Дивіться передусім на cache-references, а не тільки на cache-misses: саме кількість звернень за межі L1 і вибухає. Для звірки, масив 3000×3000 (34 МіБ), однакові 127 млн інструкцій в обох випадках:

   Обхід	cache-references	cache-misses
   за рядками	2.0 млн	1.35 млн
   за стовпцями	35.8 млн	1.59 млн

   Масив обовʼязково треба заповнити

   Якщо оголосити static int a[N][N] і нічого в нього не записати, уся ця пам’ять буде відображена на одну спільну нульову сторінку (модуль 12). Різниці між обходами не буде взагалі — за стовпцями навіть вийде менше промахів, ніж за рядками.

   Заповніть масив у циклі перед вимірюванням. Це та сама пастка, що й -O2 у демонстрації гонитви з модуля 9: система оптимізує рівно те, що ви намагаєтесь показати.

3. Система, що гальмує через диск.

   Створіть навантаження (fio або dd у циклі), знайдіть винуватця через iostat -xz і biolatency з bpftrace, покажіть розподіл затримок (модуль 13, модуль 14).

Що треба вміти підтвердити

Твердження	Чим доводиться
Ви відрізняєте очікування від обчислень	top %wa + стан процесу
Ви знайшли, у якому виклику час	strace -c -T
Ви знайшли гарячу функцію	perf report
Ви знаєте, чи процесор рахує чи чекає	perf stat, IPC
Промахи кеша виміряні, а не припущені	perf stat -e cache-misses
Затримки диска показані розподілом	biolatency або iostat -xz
Виправлення дало ефект	числа до і після для кожної задачі

Часті помилки

Профілювання без символів. perf report показуватиме адреси замість імен. Потрібні -g при збірці й пакети з відлагоджувальними символами.

Заміри без прогріву. Перший прогін читає з диска, а наступні вже з кеша сторінок (модуль 13). Різниця в сто разів, і до вашої оптимізації вона не має жодного стосунку.

Оптимізація не того. Функція займає вісімдесят відсотків часу, але викликається там, де програма й так чекає на диск. Тому й починають із першого пункту порядку дій.

strace як профілювальник. Він сповільнює програму в рази, бо перехоплює кожен виклик. Для розподілу часу між викликами придатний, для абсолютних чисел ні.

Висновок без другого виміру. «Стало швидше» без чисел до і після — це не результат.

Далі, якщо цікаво

Побудувати флейм-граф із perf record і подивитися, як виглядає той самий профіль у вигляді дерева викликів. Або написати власний однорядковий bpftrace, що рахує розподіл затримок конкретного системного виклику.