70 lines
		
	
	
		
			6.0 KiB
		
	
	
	
		
			Markdown
		
	
	
			
		
		
	
	
			70 lines
		
	
	
		
			6.0 KiB
		
	
	
	
		
			Markdown
		
	
	
---
 | 
						||
title: Анализ системы
 | 
						||
description: 
 | 
						||
published: true
 | 
						||
date: 2023-11-15T18:00:50.962Z
 | 
						||
tags: 
 | 
						||
editor: markdown
 | 
						||
dateCreated: 2023-11-15T18:00:08.853Z
 | 
						||
---
 | 
						||
 | 
						||

 | 
						||
 | 
						||
Иногда нужно понять, почему какая-то программа или сам сервер на 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 и сети.
 | 
						||
 | 
						||
Заметку заберите в закладки. Когда что-то пойдёт не так на сервере, пригодится. |