Котлеги, привет. Вдохновленный серией статей от Евгения Козлова про 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/