wiki-js/sysadmin/Linux/analize-and-test/analize-system.md

70 lines
6.0 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

---
title: Анализ системы
description:
published: true
date: 2023-11-15T18:00:50.962Z
tags:
editor: markdown
dateCreated: 2023-11-15T18:00:08.853Z
---
![image2022-8-16_9-13-53.png](/attachments/sysadmin/image2022-8-16_9-13-53.png)
Иногда нужно понять, почему какая-то программа или сам сервер на Linux тормозит. Обычно анализ производительности начинается с высокоуровневых средств top, htop, atop и т.д. Если эти инструменты не дают однозначного ответа, в чём проблема, нужно спускаться на уровень ниже.
В Linux есть встроенные профилировщики - perf и ftrace. Они входят в состав ядра. На их базе есть большой набор утилит perf-tools, о которых я хочу рассказать. Кратко я уже делал отсылки к ним в разных заметках.
Автором perf-tools является небезызвестный Brendan Gregg. Производительности Linux у него на сайте посвящена отдельная страница (https://brendangregg.com/linuxperf.html), где в том числе упоминаются эти утилиты. Там же есть видео (https://www.youtube.com/watch?v=FJW8nGV4jxY) по работе с ними.
Утилиты хорошо структурированы, описаны и приведены примеры, так что работать с ними очень просто. Покажу на конкретном примере. Допустим, нам кажется, что тормозит диск. Надо разобраться, в чём проблема.
Запускаем утилиту iolatency и смотрим latency диска. Если это современный SSD, то большая часть запросов будут укладываться в диапазон 0 -> 1 мс.
```bash
./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 и смотрим на отклик приложений:
```bash
./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 и сети.
Заметку заберите в закладки. Когда что-то пойдёт не так на сервере, пригодится.