​​Почти во всех популярных дистрибутивах Linux в составе присутствует утилита vmstat. С её помощью можно узнать подробную информацию по использованию оперативной памяти, cpu и дисках. Лично я её не люблю, потому что вывод неинформативен. Утилита больше для какой-то глубокой диагностики или мониторинга, нежели простого использования в консоли.

Если есть возможность установить дополнительный пакет, то я предпочту dstat. Там и вывод более наглядный, и ключей больше. А информацию по базовому отображению памяти хорошо перекрывает утилита free.

Тем не менее, если хочется быстро посмотреть некоторую системную информацию, то можно воспользоваться vmstat. У неё есть возможность выводить с определённым интервалом информацию в консоль. Иногда для быстрой отладки это может быть полезно. Запускать лучше сразу с парой дополнительных ключей для вывода информации в мегабайтах и с более широкой таблицей:

# vmstat 1 -w -S M

Как можно убедиться, вывод такой себе. Сокращения, как по мне, выбраны неудачно и неинтуитивно. В том же dstat такой проблемы нет. Но в целом привыкнуть можно. В man vmstat они подробно описаны, так что с интерпретацией проблем не должно возникать.

А вообще, эта заметка была написана, чтобы в неё тиснуть необычный однострочник для bash, который меня поразил своей сложностью и непонятностью, но при этом он рабочий. Увидел его в комментариях на хабре и сохранил. Он сравнивает вывод информации об использовании памяти утилиты free и cat /proc/meminfo:

# eval $(free -kw | awk '/Mem/{print "mtotal="$2"\nmused="$3"\nmfree="$4"\nmshared="$5"\nmbuffers="$6"\nmcache="$7"\nmavailable="$8}/Swap/{print "stotal="$2"\nsused="$3"\nsfree="$4}');eval $(awk -F'(: +)| ' '!/\(/{print $1"="$2}' /proc/meminfo);clear; echo -e ";;;;;\nMem;total;$mtotal;│;$MemTotal;MemTotal\nMem;used;$mused;│;$[MemTotal-MemFree-Buffers-Cached-KReclaimable];MemTotal-MemFree-Buffers-Cached-KReclaimable\nMem;free;$mfree;│;$MemFree;MemFree\nMem;shared;$mshared;│;$Shmem;Shmem\nMem;buffers;$mbuffers;│;$Buffers;Buffers\nMem;cache;$mcache;│;$[Cached+KReclaimable];Cached+KReclaimable\nMem;available;$mavailable;│;$MemAvailable;MemAvailable\nSwap;total;$stotal;│;$SwapTotal;SwapTotal\nSwap;used;$sused;│;$[SwapTotal-SwapFree];SwapTotal-SwapFree\nSwap;free;$sfree;│;$SwapFree;SwapFree\n\n" | column -t -s ";" --table-columns " ,free -kw¹,KiB¹, ,KiB²,/proc/meminfo²" --table-right "free -kw¹,KiB¹" --table-truncate "/proc/meminfo²"

Это прям какой-то царь-однострочник. Я когда его первый раз запускал, не верил, что он заработает. Но он заработал. В принципе, можно сохранить и использовать.

В завершении дам ссылку на свою заметку с небольшой инструкцией, как и чем быстро в консоли провести диагностику сервера, если он тормозит. Обратите внимание там в комментариях на вот этот. Его имеет смысл сохранить к себе.

#bash #script #perfomance

Каких только top-ов в Linux нет. Встречайте ещё один, про который большинство скорее всего не слышали - dnstop. Живёт в базовых репах:

# apt install dnstop

Пригодится в основном на локальном dns сервере, но не обязательно только там. С помощью dnstop можно в режиме реального времени смотреть статистику dns запросов, как приходящих на сервер, так и исходящих от него самого.

Для запуска надо указать сетевой интерфейс, который будем слушать:

# dnstop eth0

Если хотите сразу исключить локальные запросы сервера, то исключите его IP адрес с помощью ключа -i:

# dnstop eth0 -i 10.20.1.2

После запуска вы увидите основной экран с IP адресами источников запросов и количеством запросов. С помощью клавиш вы можете выбрать различные режимы отображения информации:

◽ s - таблица source address, экран по умолчанию после запуска
◽ d - таблица destination address
◽ t - статистика по типам запросов
◽ r - таблица кодов ответов
◽ @ - таблица source + адреса доменов 2-го уровня в запросе

Это не все горячие клавиши. Я перечислил только те, что показались полезными. Остальные возможности можно посмотреть в man.

По своей сути dnstop похож на tcpdump, потому что использует библиотеку libpcap, только она анализирует исключительно dns запросы. Результат работы можно сохранить в pcap файл с помощью ключа savefile.

#dns #perfomance

​​Вчера посмотрел короткое видео на тему тормозов php сайта. В данном примере это был Битрикс, но проблема была не в нём, а в настройках веб сервера. Мне понравился способ решения проблемы с помощью perf, поэтому решил его отдельно разобрать текстом:

▶️ Причина торможения PHP в Битриксе

Обращаю внимание на автора ролика. Он ведёт открытые уроки в Rebrain и Otus. У Отус видел его преподавателем на некоторых курсах.

В видео описана проблема, когда один и тот же сайт на одном сервере тормозит, а на другом работает нормально. Причём разница в производительности конкретного тормозного скрипта отличается во много раз. На первый взгляд не понятно, в чём проблема.

Автор взял инструмент для профилирования нагрузки perf:

# apt install linux-perf
# yum install perf

И просто запустил его встроенный топ:

# perf top

Там увидел профиль библиотеки libphp7.so, которая отвечает за исполнение php кода. Зашёл в её подробности и там увидел, что существенную нагрузку даёт исполнение функции php_pcre_exec. Я пишу подробно, потому что повторил всё то же самое на одном из своих нагруженных сайтов на Битриксе.

Исходя из этой информации автор предположил, что причина катастрофического падения производительности как-то связана с модулем php pcre. На деле так и вышло. Этот модуль был по какой-то причине отключен (хотя по умолчанию он должен быть включен, кто-то побаловался с настройками), что и приводило к жутким тормозам. Когда его включили, сайт заработал нормально.

Я обратил внимание на это видео, потому что понравилось простое и быстрое решение. Не думал, что perf может так быстро помочь. Обычно с его помощью снимают полные стек-трейсы, в которых смогут разобраться не только лишь все. Нужны глубокие знания в системных вызовах Linux, функциях ядра, аппаратных счётчиках и т.д. Я, к примеру, особо в этом не разбираюсь, поэтому и не смотрю. Но в данном примере perf довольно быстро и легко помог решить проблему. Берите на вооружение.

#perfomance

Хочу привлечь ваше внимание к моей старой публикации, к которой я сам постоянно обращаюсь. Это заметка про анализ дисковой активности в Linux. Вчера в очередной раз к ней обращался, поэтому решил и вам напомнить.

В Zabbix прилетели триггеры на тему повышенного сетевого трафика с виртуальной машины разработчиков 1C и нагрузки на общий файловый сервер, который они используют для обмена информацией. Так как разработчики внешние на аутсорсе, внимание к этой виртуалке повышенное, поэтому я сразу решил проверить, в чём дело. В общем случае это некритичные триггеры, в основной инфраструктуре у них пороги либо очень высокие, либо вообще отключены.

Зашёл на виртуалку, сразу увидел через htop, что нагрузку даёт samba. Через iftop увидел, что активно идёт трафик с указанной виртуалки. Захотелось узнать, что конкретно пишут. Тут я сходу не вспомнил утилиту, поэтому полез в указанную заметку. Что конкретно в данный момент пишется на диск смотрю командой:

# fatrace -f W
smbd(20632): W /data/1c-bases/БП обновление 2024 ТЕСТ/1Cv8.1CD

Там оказались какие-то выгрузки 1С. Сразу позвонил человеку, который отвечает за эти дела. Он подтвердил, что да, всё по плану.

Чуть раньше тоже разбирался с работой веб сервера и конкретно MySQL, смотрел, что и куда пишет служба, чтобы понять, в чём конкретно узкое место и как можно разнести файловую нагрузку. Надо было решить вопрос, почему сервер тормозил и медленно отвечал сайт.

В общем, эти утилиты по анализу дисковой активности прям топ. Сильно упрощают задачу анализа работы сервера. Перечислю их тут списком:

- btrace
- iostat
- iotop
- fatrace
- strace
- lsof
- iosnoop
- biosnoop

Ну а подробности с примерами тут.

#perfomance

​​В ОС на базе Linux есть разные способы измерить время выполнения той или иной команды. Самый простой с помощью утилиты time:

# time curl http://127.0.0.1/server-status
Active connections: 1 
server accepts handled requests
 6726 6726 4110 
Reading: 0 Writing: 1 Waiting: 0 

real 0m0.015s
user 0m0.006s
sys 0m0.009s

Сразу показал на конкретном примере, как я это использовал в мониторинге. Через curl обращаюсь на страницу со статистикой веб сервера Nginx. Дальше распарсиваю вывод и забираю в том числе метрику real, которая показывает реальное выполнение запроса. Сама по себе в абсолютном значении эта метрика не важна, но важна динамика. Когда сервер работает штатно, то эта метрика плюс-минус одна и та же. И если начинаются проблемы, то отклик запроса страницы растёт. А это уже реальный сигнал, что с сервером какие-то проблемы.

Сейчас в репозитории современных систем приехал более продвинутый инструмент для отслеживания времени выполнения консольных команд - hyperfine:

# apt install hyperfine

С его помощью можно не только измерять время выполнения разовой задачи, но и прогонять множественные тесты, сравнивать выполнение разных команд, выгружать результаты в различные форматы, в том числе json. В репозитории много примеров. Hyperfine заточен в основном на оптимизацию консольных команд, сравнение и выявление узких мест. Лично мне он больше интересен как инструмент мониторинга.

Например, в hyperfine можно обернуть какую-то команду и получить информацию по её выполнению. Покажу на примере создания дампа mysql базы:

# hyperfine --runs 1 --export-json mysqldump.json 'mysqldump --opt -v --no-create-db db01 -u'user01' -p'pass01' > ~/db01.sql'

На выходе получаем файл mysqldump.json с информацией:

{
 "results": [
  {
   "command": "mysqldump --opt -v --no-create-db db01 -u'user01' -p'pass01' > ~/db01.sql",
   "mean": 2.7331184105,
   "stddev": null,
   "median": 2.7331184105,
   "user": 2.1372425799999997,
   "system": 0.35953332,
   "min": 2.7331184105,
   "max": 2.7331184105,
   "times": [
    2.7331184105
   ],
   "exit_codes": [
    0
   ]
  }
 ]
}

Получаем команду, время выполнения и код выхода. Эти данные можно забирать в систему мониторинга или сбора логов. Удобно настроить мониторинг на среднее время выполнения команды или на код выхода. Если не нулевой, то срабатывает триггер.

Точно так же можно собирать информацию о реальном отклике сайта:

# hyperfine --runs 3 'curl -s https://github.com/'

Можно раз в минуту прогонять по 3 теста с нужной вам локации, записывать результат и сравнивать со средним или с заданным пределом.

Я привел примеры только для мониторинга. Так то hyperfine многофункционален. Так что берите на вооружение.

#linux #мониторинг #perfomance

Для того, чтобы получить быстрое представление о производительности системы, а тем более сравнить её с другой, можно воспользоваться простой утилитой sysbench. Во времена Centos её приходилось ставить либо вручную, либо из стороннего репозитория. В Debian 12 она живёт в базовой репе:

# apt install sysbench

Причём, я уже писал о ней раньше в контексте нагрузочных тестирований Mysql или Postgresql сервера. Это наиболее простое и поэтому популярное решение для подобных задач. Если тюните СУБД где-то на тесте, то возьмите на вооружение эту утилиту и делайте на ней прогоны.

А сейчас перейдёт к стандартным нагрузочным тестам системы. Для CPU, судя по man утилиты, есть только один тест - --cpu-max-prime, генератор простых чисел. Можно указать верхнюю границу чисел, а можно этого не делать. По умолчанию запускается в одном потоке на одном ядре CPU на 10 секунд с лимитом в 10000:

# sysbench cpu run

Смотрим на events per second и total number of events, чем больше, тем лучше.

Тест памяти, соответственно:

# sysbench memory run

Смотреть надо на Total operations или transferred MiB/sec. В абсолютных значениях это мало что скажет. Подойдёт для сравнения двух серверов.

С тестированием диска не всё очевидно и просто. Там уже имеет смысл заморочиться с параметрами, так надо учесть системный кэш, кэш гипервизора, если он есть, кэш рейд контроллера, если он используется и т.д. То есть надо немного разбираться в теме, иначе можно получить неверные представления о результатах теста. Как минимум, надо задать размер тестового файла больше оперативной памяти сервера и выбрать тип операций для теста. Например, запустим тест на последовательную запись суммарного объёма файлов в 10G:

# sysbench fileio --file-total-size=10G --file-test-mode=seqwr run

По умолчанию запись идёт в один поток. В результатах смотреть надо на Throughput written, MiB/s, total number of events. Тут ещё на Latency имеет смысл посмотреть. Важный параметр для дисков.

Посмотреть все доступные настройки можно так:

# sysbench fileio help

В целом, там более-менее всё понятно по описанию. Можно менять количество потоков, размер блоков, типы операций, использование флагов sync, dsync или direct. Если вам всё это не знакомо, имеет смысл изучить. Это нужная база для понимания работы в Linux с дисками.

После работы тестов на диск, остаются тестовые файлы. Их надо удалить либо вручную, либо автоматически:

# sysbench fileio --file-total-size=10G --file-test-mode=seqwr cleanup

Запускаете ту же команду, только на конце не run, а cleanup.

Такая вот простая и полезная утилита. Я во время написания заметки гонял её на двух разных VPS. По памяти и процу разница была примерно в 1,5-2 раза. А по диску почти идентично. Когда ты арендуешь виртуалку, невозможно оценить, насколько стоимость будет соотноситься с производительностью. Только на тестах можно это увидеть.

Sysbench, кстати, можно гонять и в Windows, в WSL. Я погонял на своём рабочем ноуте в виртуалке HyperV и в WSL. Тесты по CPU и Памяти идентичны в пределах стат погрешностей. Сделал несколько прогонов. Думал, что по диску будет разница, но тоже нет. Тесты последовательной записи проходят идентично. Другие не делал.

⇨ Исходники

#perfomance

​​Как быстро и малыми усилиями попытаться выяснить, почему что-то тормозит в php коде сайта? Расскажу, с чего уместнее всего начать расследование, если вы используете php-fpm. Если нет каких-то особых требований, то лично я всегда исользую именно его.

У него есть две простые настройки, которые можно применить в нужном пуле, когда проводите расследование:

slowlog = /var/log/php-fpm/site01.ru.slow.log
request_slowlog_timeout = 1s

Таймаут выставляете под свои требования. Если сайт в целом тормозной (bitrix, админка wordpress), то 1 секунда слишком малый интервал, но в идеале хочется, чтобы весь код выполнялся быстрее этого времени.

Далее необходимо перезаустить php-fpm и идти смотреть лог:

# systemctl restart php8.0-fpm

В логе запросов будет не только информация о скрипте, который долго выполняется, но и его трассировака. Она будет включать в себя все инклюды и функции. То, что было вызвано сначала, будет внизу трейса, последняя функция - в самом верху. Причём верхней функцией будет та, что выполнялась в момент наступления времени, указанного в request_slowlog_timeout. Часто именно она и причина тормозов.

Разобраться во всём этом не такая простая задача, но в целом выполнимая даже админом. Самое главное, что иногда можно сразу получить подсказку, которая ответит на ворос о том, что именно томозит. Бывает не понятно, какой именно запрос приводит к выполнению того или иного скрипта. Нужно сопоставить по времени запрос в access.log веб сервера и slowlog php-fpm. 

Очень часто тормозят какие-то заросы к внешним сервисам. Они могут делаться, к примеру, через curl_exec. И вы это сразу увидите в slowlog в самом верху трейса. Нужно будет только пройтись по функуциям и зависимостям, и найти то место, откуда функция с curl вызывается. Также часто в самом верху трейса можно увидеть функцию mysqli_query или что-то в этом роде. Тогда понятно, что тормозят запросы к базе.

По факту это самый простой инструмент, который имеет смысл использовать в самом начале разборов. Зачастую с его помощью можно сразу найти проблему. Ну а если нет, то можно подключать strace и смотреть более детально, что там внутри происходит. Но это уже сложнее, хотя какие-то простые вещи тоже можно сразу отловить. Тот же внешний тормозящий запрос тоже будет виден сразу.

#php #webserver #perfomance

​​Я недавно рассказывал про namespaces в Linux. На основе этой изоляции работает множество софта. Далее будет пример одного из них, который использует network namespaces для записи дампа трафика конкретного приложения.

Речь пойдёт про nsntrace. Это относительно простое приложение, которое, как я уже сказал, может собрать дамп трафика отдельного приложения. Для этого оно делает следующие вещи:

1️⃣ Создаёт отдельный network namespace для исследуемого приложения.
2️⃣ Для того, чтобы там был доступ в интернет, создаются виртуальные сетевые интерфейсы. Один в новом namespace, другой в основном. В новом используется шлюз из основного namespace. Из-за этой схемы у запускаемого приложения будет IP адрес виртуальной сети.
3️⃣ Средствами iptables трафик натится из виртуальной сети в реальную.
4️⃣ Запускает приложение в новом namespace и собирает его трафик с помощью libpcap. Результат сохраняет в обычный pcap файл.

Nsntrace есть в базовых репах Debian:

# apt install nsntrace

Самый банальный пример, чтобы проверить работу:

# nsntrace wget google.com

На выходе получаем nsntrace.pcap, который можно посмотреть тут же, если у вас есть tshark:

# tshark -r nsntrace.pcap

Можно и в режиме реального времени наблюдать:

# nsntrace -o - wget google.com 2> /dev/null | tshark -r -

Помимо обычных приложений, снимать трафик можно и со скриптов:

# nsntrace php script.php
# nsntrace python script.py

Проверим на простом python скрипте:

import requests
res = requests.get('https://ya.ru')

Запускаем анализ сетевой активности:

# nsntrace python3 script.py
Starting network trace of 'python3' on interface eth0.
Your IP address in this trace is 172.16.42.255.
Use ctrl-c to end at any time.

Finished capturing 57 packets.

Смотрим:

# tshark -r nsntrace.pcap

Можно передать .pcap на другую машину и посмотреть в Wireshark.

Удобный инструмент. Нужен не часто, но конкретно для скриптов мне реализация понравилась. Обычно это нетривиальная задача, посмотреть, куда он стучится и что делает. Нужно вычленять именно его запросы из общего трафика, а это не всегда просто. Либо трассировку работы делать, что тоже сложнее, чем просто воспользоваться nsntrace.

#network #perfomance

​​В Linux есть простой и удобный инструмент для просмотра дисковой активности в режиме реального времени - iotop. У него формат вывода похож на традиционный top, только вся информация в выводе посвящена дисковой активности процессов.

В последнее время стал замечать, что в основном везде используется iotop-c. Это тот же iotop, только переписанный на C. Новая реализация поддерживается и понемногу развивается, в то время, как оригинальный iotop не развивается очень давно.

В каких-то дистрибутивах остались обе эти утилиты, а в каких-то iotop полностью заметили на iotop-c. Например, в Debian остались обе:

# apt search iotop

iotop/stable 0.6-42-ga14256a-0.1+b2 amd64
simple top-like I/O monitor

iotop-c/stable,now 1.23-1+deb12u1 amd64 [installed]
simple top-like I/O monitor (implemented in C)

А в Fedora iotop полностью заменили на iotop-c, с сохранением старого названия.

Так что если захотите воспользоваться iotop, чтобы отследить дисковую активность отдельных процессов, то ставьте на всякий случай сразу iotop-c. Программа простая и удобная. Запустили, отсортировали по нужному столбцу (стрелками влево или вправо) и смотрим активность. Обычно в первую очередь запись интересует.

Напомню, что у меня есть небольшая заметка про комплексный анализ дисковой активности в Linux с помощью различных консольных утилит.

#perfomance

Вчера в заметке я немного рассказал про планировщики процессов для блочных устройств в Linux и чуток ошибся. Тема новая и непростая, особо не погружался в неё, поэтому не совсем правильно понял. Немного больше её изучил, поэтому своими словами дам краткую выжимку того, что я по ней понял и узнал.

Наиболее актуальны сейчас следующие планировщики:

🔹mq-deadline - по умолчанию отдаёт приоритет запросам на чтение.
🔹kyber - более продвинутый вариант deadline, написанный под самые современные быстрые устройства, даёт ещё меньшую задержку на чтение, чем deadline.
🔹CFQ и BFQ - второй является усовершенствованной версией первого. Формируют очередь запросов по процессам и приоритетам. Дают возможность объединять запросы в классы, назначать приоритеты.
🔹none или noop - отсутствие какого-либо алгоритма обработки запросов, простая FIFO-очередь.

В современных системах на базе ядра Linux планировщик может выбираться автоматически в зависимости от используемых дисков. Разные дистрибутивы могут использовать разные подходы к выбору. Посмотреть текущий планировщик можно так:

# cat /sys/block/sda/queue/scheduler
[none] mq-deadline

Тут я вчера ошибся. Не понял, что в данном случае используется планировщик none. То, что выделено в квадратных скобках - используемый планировщик. Вот ещё пример:

# cat /sys/block/vda/queue/scheduler
[mq-deadline] kyber bfq none

Тут выбран планировщик mq-deadline. Поддержка планировщика реализована через модули ядра. Если вы хотите добавить отсутствующий планировщик, то загрузите соответствующий модуль.

# cat /sys/block/sda/queue/scheduler
[none] mq-deadline
# modprobe kyber-iosched
# cat /sys/block/sda/queue/scheduler
[none] mq-deadline kyber
# echo kyber > /sys/block/sda/queue/scheduler
# cat /sys/block/sda/queue/scheduler
mq-deadline [kyber] none

Загрузили модуль kyber-iosched и активировали этот планировщик. Действовать это изменение будет до перезагрузки системы. Для постоянной работы нужно добавить загрузку этого модуля ядра. Добавьте в файл /etc/modules-load.d/modules.conf название модуля:

kyber-iosched

А для применения планировщика создайте правило udev, например в отдельном файле /etc/udev/rules.d/schedulerset.rules:

ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sd?", ATTR{queue/scheduler}="kyber"

В виртуальных машинах чаще всего по умолчанию выставляется планировщик none и в общем случае это оправдано, так как реальной записью на диск управляет гипервизор, а если есть рейд контроллер, то он. К примеру, в Proxmox на диски автоматически устанавливается планировщик mq-deadline. По крайней мере у меня это так. Проверил на нескольких серверах. А вот в виртуалках с Debian 12 на нём автоматически устанавливается none. Хостеры на своих виртуальных машинах могут автоматически выставлять разные планировщики. Мне встретились none и mq-deadline. Другие не видел.

Теперь что всё это значит на практике. Оценить влияние различных планировщиков очень трудно, так как нужно чётко эмулировать рабочую нагрузку и делать замеры. Если вам нужно настроить приоритизацию, то выбор планировщика в сторону BFQ будет оправдан. Особенно если у вас какой-то проект или сетевой диск с кучей файлов, с которыми постоянно работают, а вам нужно часто снимать с него бэкапы или выполнять какие-либо ещё фоновые действия. Тогда будет удобно настроить минимальный приоритет для фоновых процессов, чтобы они не мешали основной нагрузке.

Если у вас быстрые современные диски, вам нужен приоритет и минимальный отклик для операций чтения, то имеет смысл использовать kyber. Если у вас обычный сервер общего назначения на обычный средних SSD дисках, то можно смело ставить none и не париться.

Некоторые полезные объёмные материалы, которые изучил:
🔥https://selectel.ru/blog/blk-mq-tests/ (много тестов)
⇨ https://habr.com/ru/articles/337102/
⇨ https://redos.red-soft.ru/base/arm/base-arm-hardware/disks/using-ssd/io-scheduler/
⇨ https://timeweb.cloud/blog/blk-mq-i-planirovschiki-vvoda-vyvoda

#linux #kernel #perfomance