​​Иногда нужно понять, почему какая-то программа или сам сервер на Linux тормозит. Обычно анализ производительности начинается с высокоуровневых средств top, htop, atop и т.д. Если эти инструменты не дают однозначного ответа, в чём проблема, нужно спускаться на уровень ниже.

В Linux есть встроенные профилировщики - perf и ftrace. Они входят в состав ядра. На их базе есть большой набор утилит perf-tools, о которых я хочу рассказать. Кратко я уже делал отсылки к ним в разных заметках.

Автором perf-tools является небезызвестный Brendan Gregg. Производительности Linux у него на сайте посвящена отдельная страница, где в том числе упоминаются эти утилиты. Там же есть видео по работе с ними.

Утилиты хорошо структурированы, описаны и приведены примеры, так что работать с ними очень просто. Покажу на конкретном примере. Допустим, нам кажется, что тормозит диск. Надо разобраться, в чём проблема.

Запускаем утилиту iolatency и смотрим latency диска. Если это современный SSD, то большая часть запросов будут укладываться в диапазон 0 -> 1 мс.
# ./iolatency
 >=(ms) .. <(ms)  : I/O   |Distribution             |
    0 -> 1    : 155   |######################################|
    1 -> 2    : 10    |###                  |
    2 -> 4    : 19    |#####                 |
    4 -> 8    : 47    |############             |
    8 -> 16   : 34    |#########               |
   16 -> 32   : 5    |##                  |

Мы видим, что много запросов имеют latency значительно выше. Попробуем разобраться, что именно отвечает медленнее. Запускаем iosnoop и смотрим на отклик приложений:
# ./iosnoop
Tracing block I/O. Ctrl-C to end.
COMM     PID  TYPE DEV   BLOCK    BYTES   LATms
jbd2/sda3-28 286  WS  8,0   10834312   32768   0.72
kworker/2:1H 140  WS  8,0   10834376   4096    0.31
sh      48839 W  8,0   16379904   1073152   5.23
sh      48839 W  8,0   16382000   8192    5.12
sh      48839 W  8,0   16382016   1310720   7.71
sh      48839 W  8,0   16384576   262144   8.88
sh      48839 W  8,0   16387648   229376  11.20
sh      48839 W  8,0   16385088   1310720  14.12
sh      48839 W  8,0   16388096   1310720  32.67
sh      48839 W  8,0   16390656   12288   32.67
jbd2/sda3-28 286  WS  8,0   10834384   28672   0.67

Я для теста в соседней консоли запустил tar со сжатием, так что все медленные запросы были от него. В данном случае в качестве приложения указана оболочка sh, потому что tar запускает gzip в ней.

Если у вас несколько дисков в системе и они разные - SSD и HDD, то после общего запуска iolatency, можно запустить с анализом конкретного диска. В одном из примеров Brendan Gregg показывает, что отклик обычного HDD со смешанной нагрузкой read/write может быть существенно уменьшен изменением длины очереди со стандартных 128 до 4:
# echo 4 > /sys/block/xvda1/queue/nr_requests
Указанные выше утилиты позволят проанализировать это и оценить результат, подобрать нужное значение.

Расскажу ещё про утилиту opensnoop. Она делают одну простую вещь - с помощью системных вызовов open() показывает открытые файлы и приложения, которые их открывают. Очень удобно для быстрого анализа того, что вообще происходит с диском.
# ./opensnoop
Вывод можно ограничить каким-то отдельным процессом по PID, или посмотреть файлы по маске:
# ./opensnoop -p 181
# ./opensnoop 'log$'
Она же с помощью ключа -x может показать неудавшиеся попытки открыть файл. Это может быть очень полезно в некоторых ситуациях. Например, стартует сервис и не принимает настройки из конфига. Запустив opensnoop с этим ключом можно увидеть, что сервис пытается открыть конфиг по другому пути, а не там, где он у вас лежит.

Утилиты очень простые для освоения и использования. При этом позволяют выполнить низкоуровневый анализ работы системы и найти узкие места. Я показал пример с диском, но там же в репозитории есть инструменты для анализа cpu и сети.

Заметку заберите в закладки. Когда что-то пойдёт не так на сервере, пригодится.

#linux #bash #perfomance