📎 Dive in performance tools. Часть 1️⃣ [sysdig]

Котлеги, привет. Вдохновленный серией статей от Евгения Козлова про CPU, Memory Models, Concurrency, Multiprocess, Multithreading и Async, я решил написать свой цикл статей по инструментам диагностики производительности linux с примерами.

Сегодняшний обзор я начну с тулы, которая по своей сути является серебрянной пулей в вопросах диагностики проблем с производительностью - sysdig. Конечно, чаще всего ее использование бывает избыточным, но может настать тот момент, когда штатных средств может не хватить и на помощь придет sysdig.

Long story short - sysdig использует модуль ядра для перехвата системных вызовов и событий, что открывает нам невероятные возможности в плане диагностики. Вы буквально можете расковырять практически все что происходит у вас в системе. Можно использовать realtime-диагностику или собрать трейс с системы за определенный период, обычно при проблемах достаточно до 30 секунд сбора данных.

# Установка sysdig
curl -s https://download.sysdig.com/stable/install-sysdig | sudo bash

Есть небольшой минус - sysdig требует заголовки ядра (kernel headers), потому что он использует модуль ядра для перехвата системных вызовов и событий. Но глобально это влияет только на скорость установки и требуется немного места.

Допустим у вас есть какая-то лагучая нода и базовые инструменты дигностики/логи вам не особо помогли. Давайте посмотрим на живом примере как ее использовать.

# Запускаем запись всех эвентов на 30 секунд 
sysdig -w capture.scap -M 30

Конечно можно не использовать GUI, а вытащить из трейса событий нужные данные. Но это обычно работает, если вы точно знаете что искать. Например так] (без GUI)

# Вывести срезы которые доступны в этом трейсе (тут вы получите список срезов в различных категориях. Например, bottlenecks - cамые медленные системные вызовы) 
sysdig -r capture.scap  -cl

# выведем top процессов утилирующих cpu
root@server:~# sysdig -r capture.scap -c topprocs_cpu
CPU%                Process             PID
--------------------------------------------------------------------------------
15.00%              redis-server        1095390
12.60%              redis-server        1095391
12.20%              redis-server        1095375
....

# Показать top файлов с которыми велась работа (R+W) 
root@server:~# sysdig -r capture.scap -c topfiles_bytes proc.name=redis-server
Bytes               Filename
--------------------------------------------------------------------------------
72.00M              /data/temp-27.rdb
40.00M              /data/temp-28.rdb
82.72KB             /proc/self/stat
.....

Как я и сказал ранее, все эти данные есть в realtime и можно просто запустить GUI csysdig, но проблема может быть плавающая. В таком случае есть шанс просто пропустить нужные данные. Поэтому, я рекомендую снимать трейс эвентов и работать с ним.

# Открываем консольный GUI и скармливаем ему capture.scap
csysdig -r ./capture.scap

После этого переходим в режим Views (F2) и можем нырять на столько глубоко на сколько у вас хватит фантазии.

Перед нами открываются все тайны нашей системы: что именно передавалось установленным соединением определенного процесса. Сколько данных было передано, порты, ip адреса и тд. Какие ошибки происходили в системе и в каких процессах. Какие процессы какие файлы писали с каким рейтом. Какие открывались каталоги, какие контейнеры работали и какие процессы были запущеные внутри, какие действия делали эти контейнеры. Какие происходили ошибки Page Faults. Где какой был латенси на файлах. Какие порты были открыты и сколько с них было переданно данных. Этот список можно продолжать бесконечно.

А на этом все - спасибо за внимание.

В следующий раз расскажу о более простых инструментах первичной диагностики. А также попробую записать видео-урок с разбором инструмента

Ссылка на habr: https://habr.com/ru/articles/876160/