Коли система раптом «підвисає», а load average летить у космос, час включати дедукцію і збирати точні артефакти: трасування ядра, вибірку з perf, eBPF-профілі та coredump. Я, Kernelka, покажу вам швидкий та чіткий план: що дивитися першочергово, як зібрати докази в термінал Linux і як їх читати без паніки 😊

Що таке load average і чому він росте

Load average — це середня довжина черги задач, які виконуються або хочуть виконуватися (runnable), плюс задачі в непреривному очікуванні (uninterruptible, стан D). Високий loadavg буває через:

  • CPU-bound навантаження (процеси буксують на процесорі);
  • I/O-bound (диски або мережа повільні, багато D-стану);
  • contention: блокування, м’ютекси, spinlock-и;
  • thundering herd або черги планувальника.

Пам’ятайте: сам по собі великий loadavg — не вирок. Важливо зрозуміти, хто і чому стоїть у черзі.

Експрес-діагностика (5–10 хвилин)

Швидкий зріз стану системи, поки «симптоми живі». Ці команди безпечні і корисні для Linux моніторинг у проді:

# 1) Огляд навантаження
uptime; cat /proc/loadavg

# 2) Хто їсть CPU/пам'ять (зручніше через htop та top)
top -b -n1 | head -n 40
# або
htop  # інтерактивно (натисніть H, щоб показати/сховати потоки)

# 3) Хто застряг у D-стані та на чому завис (wchan)
ps -eo pid,ppid,stat,comm,pcpu,pmem,wchan:32 --sort=-pcpu | head -n 40

# 4) I/O-вузькі місця
vmstat 1 5
iostat -x 1 5   # пакет sysstat

# 5) Перевірка ядра на hung tasks і помилки
dmesg -T | tail -n 100
journalctl -k -n 200 --no-pager

Якщо ви бачите багато процесів у статусі D та високі await/avgqu-sz по дисках — перейдіть до блоку I/O. Якщо CPU 100% на одному процесі — відразу «стріляємо» у perf.

Глибинний збір даних: trace, perf, eBPF

Kernel stack traces: швидкий знімок «хто де застряг»

Stack-трейси всіх задач ядра дуже корисні для зависань та lockup-ів. Увімкніть magic SysRq та зніміть трейс:

# Увімкнути SysRq (тимчасово до перезавантаження)
echo 1 | sudo tee /proc/sys/kernel/sysrq

# Зняти стек-трейси всіх задач
echo t | sudo tee /proc/sysrq-trigger

# Переглянути в журналі ядра
journalctl -k -n 500 --no-pager | less

Шукайте підозрілі ланцюжки блокувань, довгі виклики драйверів дисків/мережі, або спін у планувальнику.

perf: гарячі функції і флеймграфи

Perf дає семплінг CPU і стеків. Спочатку встановіть інструменти і символи:

# Ubuntu/Debian
sudo apt update
sudo apt install -y linux-tools-common linux-tools-$(uname -r) linux-cloud-tools-$(uname -r) \
  perf-tools-unstable bpfcc-tools bpftrace
# (необов'язково) символи користувацьких бібліотек
sudo apt install -y libc6-dbg

Збір загальної картини на рівні системи (15 секунд):

sudo perf record -F 99 -a -g -- sleep 15
sudo perf report  # дивимося розподіл за стек-трейсами
# або вивід у текст
sudo perf script > perf.stacks

Для конкретного процесу:

PID=<винний_pid>
sudo perf record -F 99 -p "$PID" -g -- sleep 15
sudo perf report

Підказка: Якщо видно багато часу в sys_* та vfs_* — це файлові операції; якщо у futex_* — чекаємо на м’ютекс; якщо у tcp_* — мережеві затримки.

eBPF: off-CPU та затримки планувальника

eBPF-інструменти з BCC і bpftrace дозволяють побачити не лише те, де витрачається CPU, а й де процеси чекають (off-CPU) — класична причина високого loadavg.

# Латентність планувальника (в мкс)
sudo /usr/share/bcc/tools/runqlat 5

# Off-CPU час (збір 10 с, потребує BCC offcputime)
sudo /usr/share/bcc/tools/offcputime -f 10 > offcpu.folded

# bpftrace-профіль стеків ядра
sudo bpftrace -e 'profile:hz:99 { @[kstack] = count(); }' -d -c 'sleep 10' 2>/dev/null | head

Файл offcpu.folded зручно візуалізувати флеймграфом (FlameGraph): якщо домінує певний драйвер або futex_wait_queue_me — ви знайшли джерело очікувань.

ftrace/trace-cmd: покадрова історія викликів

Якщо потрібна деталізація по функціях ядра:

sudo trace-cmd record -p function_graph -a -o hang.dat -F sleep 10
sudo trace-cmd report hang.dat | less

Шукайте довгі функції (time delta), повторювані ретраї або довгі виклики I/O.

strace: коли підозрюєте системні виклики

PID=<винний_pid>
sudo strace -f -ttT -p "$PID" -o strace.log  # з часами і тривалістю

Якщо бачите довгі read()/write()/poll() — з диском або мережею біда. Довгий futex() — контеншн на блокуваннях.

Аналіз coredump за 2 хвилини

Коли процес упав або його краще «впіймати на гарячому», корисний coredump. Увімкніть дампи та заберіть стек усіх потоків:

# Дозволити створення coredump'ів у сесії
ulimit -c unlimited

# Якщо systemd-coredump
coredumpctl list | head
coredumpctl gdb <PID або exe> --batch -ex 'thread apply all bt full' -ex 'quit' > core.bt

# Якщо маєте core-файл і бінарник
gdb -q /path/to/bin /path/to/core -ex 'set pagination off' \
   -ex 'thread apply all bt full' -ex 'quit' > core.bt

У backtrace шукайте deadlock-и (всі нитки стоять у futex_wait), рекурсії, або блокування на I/O.

Альтернативні способи і збір у «польових умовах»

# Швидкий збір діагностики в папку artifacts
TS=$(date +%Y%m%d-%H%M%S); DIR=diag-$TS; mkdir "$DIR"
{
  echo '=== uptime/loadavg ==='; uptime; cat /proc/loadavg
  echo '=== top ==='; top -b -n1 | head -n 60
  echo '=== ps (wchan) ==='; ps -eo pid,ppid,stat,comm,pcpu,pmem,wchan:32 --sort=-pcpu | head -n 80
  echo '=== vmstat/iostat ==='; vmstat 1 3; iostat -x 1 3 || true
  echo '=== dmesg tail ==='; dmesg -T | tail -n 200
} &> "$DIR/quick.txt"

# Семплінг perf (10 c)
sudo perf record -F 99 -a -g -- sleep 10 && sudo perf script > "$DIR/perf.stacks"

# Kernel stacks через SysRq
echo 1 | sudo tee /proc/sys/kernel/sysrq; echo t | sudo tee /proc/sysrq-trigger
journalctl -k -n 1000 --no-pager > "$DIR/kern.log"

echo "Saved to $DIR" && ls -lah "$DIR"

Такий набір часто достатній, щоб переслати артефакти колегам і знайти винуватця.

GUI-спосіб (коли зручно візуально)

  • Hotspot (KDE) — відкрийте perf.data і одразу бачите флеймграфи, символи, відсотки.
  • GNOME System Monitor / KDE System Monitor — швидко знайти «пожирачів» CPU/пам’яті.
  • Speedscope — імпортуйте perf.script або folded-стеки для інтерактивного аналізу.

GUI — не заміна CLI, але допомагає швидко зорієнтуватися та показати результати колегам 🌈

FAQ

Чому perf каже «Permission denied» або «Unable to open /proc/sys/kernel/kptr_restrict»?
Запустіть з sudo. Для символів ядра: sudo sysctl kernel.kptr_restrict=0 і kernel.perf_event_paranoid=1 (або 0 у проді з обережністю).

perf report без символів — бачу лише адреси. Що робити?
Встановіть відлагоджувальні символи для користувацьких бібліотек (libc6-dbg) і переконайтесь, що встановлені пакети linux-tools-$(uname -r). Для власних сервісів зберігайте build-id та dSYMs.

coredump не з’являється.
Перевірте ulimit -c, політики systemd-coredump (Storage, ProcessSizeMax), а також шлях для ядра: cat /proc/sys/kernel/core_pattern.

Багато процесів у D-стані — що це?
D означає непреривне очікування I/O. Подивіться iostat -x, dmesg на помилки дисків/RAID/NFS. eBPF offcputime/runqlat підкажуть, де саме чекаєте.

Чи впливають perf/eBPF на продуктивність?
Так, але помірно при типових частотах семплінгу (99 Гц). У проді збирайте короткими інтервалами.

Як зібрати трейси в Docker/Kubernetes?
Запускайте perf/eBPF на хості з -a або з дозволами CAP_SYS_ADMIN/CAP_PERFMON. Для coredump використовуйте coredumpctl на ноді.

Порада від Kernelka

Заведіть «швидку аптечку» діагностики і перевіряйте її на кожному новому сервері. Документуйте, які саме версії perf/bpftrace стоять, та тримайте шаблон команд. Це зекономить години у найнепередбачуваніший момент 😉

Підсумок

  • Почніть з огляду: uptime, htop та top, ps з wchan, dmesg.
  • Зніміть kernel stacks (SysRq-t) та perf -a -g 10–15 с для «теплової карти».
  • Використайте eBPF (runqlat, offcputime), щоб спіймати off-CPU затримки.
  • Якщо процес падає — швидко заберіть coredump і зробіть thread backtrace.
  • Зберіть артефакти скриптом і поділіться з командою для оптимізація продуктивності.
  • GUI (Hotspot, System Monitor) допомагає візуалізувати результати.