Linux: профілювання продуктивності сервера

Коли сервер «гальмує», перше питання — яка саме підсистема впирається у стелю: CPU, диск, пам'ять чи мережа. Профілювання — це не ворожіння, а послідовний обхід цих чотирьох точок із конкретними командами і конкретними числами у виводі.

Базові інструменти діагностики

Діагностика високого навантаження CPU

# Знайти процес із максимальним навантаженням
top -b -n 1 | head -20

# Подивитися, що робить процес
strace -p PID -c

# Flamegraph (якщо встановлено perf)
perf record -g -p PID sleep 30
perf script | stackcollapse-perf.pl | flamegraph.pl > cpu.svg

Окремо варто дивитися load average проти кількості ядер: nproc покаже їхню кількість, і якщо перше число з uptime тримається помітно вище цього числа годинами, а не хвилинами, — це вже не сплеск, а системна нестача CPU, і профілювання одного процесу не замінить апгрейд чи оптимізацію коду.

Діагностика повільного диска

# I/O статистика за пристроями
iostat -x 1 5

# Який процес навантажує диск
iotop -o -b -n 5

# Перевірка стану RAID / SMART
smartctl -a /dev/sda

У виводі iostat -x ключова колонка — %util: значення, близьке до 100%, означає, що пристрій зайнятий майже постійно, а колонка await показує середню затримку запиту в мілісекундах — зростання await за незмінного util зазвичай вказує на деградацію самого диска, а не просто зростання навантаження.

Діагностика нестачі пам'яті

# Зведення щодо пам'яті
free -h

# Топ процесів за RAM
ps aux --sort=-%mem | head -10

# Лог OOM killer (кого було вбито)
dmesg | grep -i "killed process"

Розбір типових повідомлень і метрик

Рядок Out of memory: Killed process 4821 (mysqld) total-vm:2145728kB у виводі dmesg — це не помилка mysqld, а рішення ядра: OOM killer обрав процес із найбільшим споживанням пам'яті і примусово завершив його, щоб не допустити повного зависання системи. Після такої події треба дивитися, що стало причиною зростання споживання — витік, невдалий запит чи просто нестача RAM під поточне навантаження, а не просто перезапускати сервіс.

Високий %wa (iowait) у top за низького %us і %sy означає, що процесор простоює не тому, що йому нема чого робити, а тому що чекає на відповідь від диска. Апгрейд CPU в такій ситуації не допоможе — вузьке місце фізично в дисковій підсистемі або в конкретному процесі з надмірним I/O, який знаходиться через iotop.

Load average вище за кількість ядер за нормального CPU та I/O — часто означає не обчислювальне навантаження, а чергу процесів, що чекають на недоступний ресурс: заблокований файл, семафор чи повільний зовнішній запит (наприклад, до бази даних чи API). У такій ситуації ps aux покаже процеси у стані D (uninterruptible sleep) — саме вони формують load average, а не CPU-навантаження.

Порівняння підходів до діагностики

Коли профілювання на самому сервері недостатньо

• Проблема проявляється рідко і непередбачувано — разовий запуск top у момент затишшя нічого не покаже, потрібен постійний збір метрик на кшталт системи моніторингу з історією.
• Вузьке місце не в самому VDS, а в зовнішній залежності (повільний DNS, віддалене API, мережевий провайдер) — локальні інструменти покажуть лише те, що процес «чекає», але не пояснять, чого саме чекає мережа зовні сервера.
• Навантаження розподілене між кількома серверами — профілювання одного VDS не побачить загальну картину балансування і перекосу навантаження між вузлами.
• Потрібна точна причина деградації коду застосунку, а не системних ресурсів, — тут системні утиліти поступаються APM-інструментам рівня застосунку.

Перевірка результату

1. Після застосованої правки (індекс у базі, доданий swap, змінений конфіг) повторіть той самий набір команд і порівняйте конкретні числа: %util диска, load average, %wa — зниження має бути вимірним, а не «на око стало швидше».
2. Перевірте, що проблема не перемістилася в інше місце: зниження навантаження на CPU іноді просто відкриває дорогу черзі запитів до диска, яка раніше була не видна за повільнішим CPU.
3. Лишіть моніторинг увімкненим хоча б добу після зміни — разова перевірка одразу після правки не покаже поведінку під вечірнім чи нічним піком навантаження.
4. Зафіксуйте baseline метрик у спокійному стані — без опорних цифр «нормального» навантаження наступну проблему доведеться діагностувати з нуля.