Нагрузка на диски в Linux

Для измерения текущей нагрузки на диски (что происходит, кто куда копирует и прочее) в Linux можно использовать iotop (и здесь же lsof) и iostat. А для тестирования возможностей дисковой системы fio. Несмотря на то, что первое, о чем можно подумать в плане попугаев — это IOPS или же Мб/сек за чтение или запись, обратите внимание на время ожидания. Примерно как если бы вы стояли в очереди в кассу: вас обслужили бы за 2 минуты, но очередь может быть минут на 30. И со стороны наблюдателя ваш процесс обслуживания будет «висеть». Именно так могут ощущать себя клиенты сервера, если время ожидания будет намного превышать время выполнения конкретной задачи. Поэтому определение длинной очереди и задержек часто бывает более важным, чем знать, что ваш диск «вау, может писать 400 Мбит/с». Нагрузка на диск может оказаться в 4000 Мбит/с в течение длительных периодов времени и все это время клиенты сервера будут недовольны.

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

IOTOP

Посмотреть, какие процессы в настоящее время создают нагрузку на диск удобно смотреть командой iotop:

Здесь видно, что в данный момент mc что-то пишет (а в это время в другом окне я в самом деле копировал кучу файлов на usb-диск в Midnight Commander (он же mc).

Понять, что коипрует mc в данный момент можно узнать командой:

IOSTAT

Пример вывода iostat на незагруженной в данный момент старенькой системе из двух SATA HDD в soft raid 1 (зеркало) mdadm:

Команда выглядела так:

-x — расширенная статистика

-t — выводить время для каждой порции замеров

-m — результаты в Мбайт

5 — интервал замеров 5 секунд.

Если нужны не история, а динамика процесса, попробуйте так:

watch iostat -x -t -m 1 2

В этом выводе r/s и w/s это отправленные к устройству запросы на выполнение (IOPS, которые хотелось бы, чтобы устройство выполнило).

await — время, включающее ожидание выполнения запроса (как если бы вы встали в очередь в кассу и ждали бы, пока вас обслужат).

svctm — время, реально затраченное на выполнение запроса (время «на самой кассе»).

Для обычных SATA дисков нагрузка IOPS где-то до 100-130 вполне выполнимая. В момент проведения замеров запрошенная нагрузка была 40 IOPS, поэтому запрос практически в очереди и не стоял, его обслужили почти сразу (на «кассе» никого не было). Поэтому await практически равен svctm.

Другое дело, когда нагрузка на диск вырастает:

%iowait — простой процессора (время в процентах) от или процессоров, в то время пока обрабатывались запросы. Т.е. в среднем процессор отдыхал почти 50% времени.

%user — загруженность процессора пользовательскими приложениями. По этому параметру видно, например, что в данный период процессор был почти не занят. Это важно, т.к. может помочь отсечь подозрения в тормозах из-за процессора.

Замер сделан во время переноса большого количества писем из одной папки IMAP в другую. Особо обратите внимание на await и svctm. Налицо длинная очередь (отношение await к svctm). Дисковая система (или чипсет, или медленный контроллер SATA, или. ) не справляется с запрошенной нагрузкой (w/s).. Для пользователей в этот момент все выглядело просто — сервер тупит или даже завис.

Заранее проверить производительность дисков можно с помощью fio. Также можно примерно оценить на одной машине производительность дисков и понимать, какой уровень «в среднем по больнице» вы можете ожидать. Это, конечно же, не правильно, но оценить все же поможет. Глубже анализировать результаты, а, главное, методики тестов мне пока трудно.

# yum install fio

# apt-get install fio

В общем виде запуск выглядит так:

Файл your.cfg (название произвольное) может быть примерно таким (пример рабочего конфига для теста на чтение):

Буферизацию не используем (buffered=0), чтение не последовательное (rw=randread).

Во время выполнения этого теста (а выполняться тест может доооолго, надоест — Ctrl+C, результаты все равно будут) можно запустить iostat и посмотреть, что происходит:

Обратите внимание на отношение await к svctm: await/svctm = 32,11..11, т.е. можно считать 32. Это и есть iodepth из конфига your.cfg. Теперь проще понять смысл iodepth — мы указываем, насколько хотим в тесте имитировать длинную очередь заданий.

Я не стал ждать два дня, Ctrl+C и вот результат:

Получили 109 iops, что в принципе нормально, диск обычный, SATA.

Источник

Выполняю установку, настройку, сопровождение серверов. Для уточнения деталей используйте форму обратной связи

Иногда бывают ситуации, когда в top’e вроде бы всё нормально, но сервер всё равно тормозит. Тогда нужно обратить внимание на нагрузки дисковой подсистемы. В статье мы рассмотрим варианты для Unix систем: FreBSD, OpenBSD, Linux, Solaris.

FreeBSD

Во FreeBSD есть штатная утилита gstat, при запуске которой без параметров мы увидим текущую нагрузку на диски.

Как видно из примера, очень большая нагрузка на диск ad4.

Так же можно смотреть и через iostat (пример из другой ОС):

А ещё можно использовать команду systat -iostat:

А что-бы определить процесс, который нагружает диски, выполним такую команду:

#top -m io -o total

OpenBSD

Для OpenBSD есть штатная утилита iostat, которая показывает нагрузку на диски+CPU usage. При обычном запуске она показывает не больше 4 дисков, но если нужно больше, то указываем все нужные диски.

Linux

Для Linux есть аналог утилиты gstat — iostat. В Debian/Ubuntu она находится в пакете sysstat.

Здесь мы поставили автообновление каждую секунду. Хочу обратить внимание на то, что первые пару выводов во внимание не брать, так как в первом выводе отображается информация из кеша, а не реальные показатели. Как видим, диски здесь не нагружены

Для определения процесса, который нагружает диски, есть утилита iotop, правда её нужно ставить отдельно.

Solaris

Для solaris существует 3 метода: zpool iostat, утилита iostat, fsstat. Единственный недостаток, это то, что мы не сможем отображать статистику отдельно по каждой из zfs, а только можем отдельно по каждому диску:

Здесь как и в случае с Linux не учитываем первый вывод. Как видим, диски простаивают (значение столбца %b — busy).

Общую картину можно так же посмотреть через fsstat:

Очень удобно просматривать информацию по конкретной zfs:

Смотрим нагрузку на диски : 5 комментариев

Программа ‘gstat’ на данный момент не установлена. Вы можете установить ее, напечатав:
apt-get install ganglia-monitor

Это не тот gstat, которым смотрят диски — просто названия одинаковые.

FreeBSD
top -m io -o total

ога ))
по моему то чё он предлагает имеет отношение к sql

если zfs на фре то «zpool iostat -vl 1» надо юзать без l
zpool iostat -v 1

Источник

Выявляем процессы с дисковой активностью в Linux

TL;DR: статья рассказывает об удобном, быстром и надежном способе определения Linux-программ, записывающих данные на диск, что помогает в выявлении большой или аномально частой нагрузки на дисковую подсистему, а также позволяет оценить накладные расходы файловой системы. Это особенно актуально для SSD в ПК, EMMC и Flash-памяти в одноплатных компьютерах.
В ходе написания статьи обнаружилось, что запись нескольких килобайт данных на файловую систему BTRFS приводит к записи 3 мегабайт реальных данных на диск.

Введение

После 7 месяцев использования нового SSD я решил проверить количество записанных данных, как их сообщает сам диск через SMART.
19.7 ТБ.
Всего за 7 месяцев я использовал 13% от гарантированного количества записанных данных, притом, что он настроен в соответствии с рекомендациями по выравниваю разделов и настройке ФС, swap у меня почти не используется, диски виртуальных машин размещены на HDD!
Это аномально большая цифра, такими темпами гарантийный TBW будет превышен раньше достижения 5-летнего срока гарантии диска. Да и не может мой компьютер писать по 93 гигабайта в сутки! Нужно проверить, сколько данных пишется на диск за 10 минут…

Total:
Writes Queued: 24,712, 2,237MiB
Writes Completed: 25,507, 2,237MiB
Write Merges: 58, 5,472KiB

Определение количества записанных данных на дисковое устройство

Мой SSD хранит количество записанных данных в параметре 241 Total_LBAs_Written, в логических блоках (LBA), а не в байтах. Размер логического блока в моём случае — 512 байт (его можно увидеть в выводе smartctl, в Sector Size). Чтобы получить байты, нужно умножить значение параметра на 512.

Программа skdump на моём SSD пытается интерпретировать значение Total_LBAs_Written как-то по-своему, из-за чего выводит 1296217.695 TB , что, очевидно, некорректно.

Чтобы узнать количество записываемой информации на уровне устройства, воспользуемся программой btrace из состава пакета blktrace . Она показывает как общую статистику за всё время работы программы, так и отдельные процессы и потоки (в т.ч. ядра), которые выполняли запись.

Запустите следующую команду, чтобы собрать информацию за 10 минут, где /dev/sdb — ваш диск:

btrace позволяет наглядно посмотреть реальное количество записанных данных, но понять, какие именно программы совершают запись, из её вывода сложно.

Определение программ, производящих запись на накопитель

Программа iotop покажет процессы, пишущие на диск, и размер записанных данных.
Наиболее удобный вывод обеспечивают следующие параметры:

В глаза бросается Firefox, записавший 283 мегабайта за несколько минут работы iotop.

Определение файлов, в которые производится запись

Информация о процессе, насилующим диск — хорошо, а пути, по которым производится запись — еще лучше.

Воспользуемся программой fatrace , которая отслеживает изменения файловой системы.

Fatrace не умеет показывать количество записанных данных вследствие использования довольно простого отслеживания факта обращения к файлам через inotify.

Из вывода видно, как хабр сохраняет мою статью в local storage браузера, пока я её пишу, а также расширение Group Speed Dial, которое, как удалось обнаружить именно с помощью fatrace, читает свои данные каждые 30 секунд. Именно читает, а не записывает: CW перед файлом говорит о том, что файл открывается на чтение и запись, с одновременным созданием файла, если он отсутствует (вызывается openat с флагом O_RDWR|O_CREAT), но не говорит, что в файл действительно писалась какая-либо информация.

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

Нет ни одного вызова write() , что говорит об отсутствии записи в файл.

Определение накладных расходов файловой системы

Большая разница в показаниях iotop и btrace натолкнула на мысль протестировать файловую систему путем ручной записи данных в файл и отслеживания показаний btrace.

Если полностью исключить запись на диск, загрузившись в emergency-режим systemd, и записать вручную пару байт данных в существующий файл, btrace на SSD с btrfs сообщает о записи 3 мегабайт реальных данных. Свежесозданная файловая система флешке размером в 8 ГБ записывает минимум 264 КиБ при записи одного байта.
Для сравнения, запись пары байт в файл на ext4 оканчивается записью 24 килобайтов данных на диск.

В 2017 году Jayashree Mohan, Rohan Kadekodi и Vijay Chidambaram провели исследование усиления записи разных файловых систем, их результаты для btrfs и ext4 при записи 4 КБ соотносятся с моими.

Источник

Кунг-фу стиля Linux: мониторинг дисковой подсистемы

Если, работая в Linux, нужно быстро взглянуть на сведения о работающих процессах — можно воспользоваться командой top , или — что немного лучше — командой htop . А как быть, если надо получить данные о состоянии дисковой подсистемы? Решить эту задачу помогут специализированные инструменты, некоторые из которых распространены далеко не так широко, как top .

Утилита iotop

Утилита iotop очень сильно похожа на top . Она выводит сведения об общем и текущем количестве операций обращения к диску для файловой системы. Кроме того, она сообщает о том, что именно интенсивнее всего нагружает диск. Экран iotop , на первый взгляд, переполнен информацией.

Вот совет по работе с этой утилитой. Если взглянуть на нижнюю часть экрана — там можно найти некоторые команды, вызываемые нажатиями на клавиши клавиатуры. Например, клавиша O скрывает (или отображает) все неактивные процессы. Это позволяет немного улучшить внешний вид сведений, выводимых iotop .

Сведения об использовании дисковой подсистемы активными процессами

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

Утилита iostat

Если вас больше интересуют данные, относящиеся к самим дискам, а не к процессам или потокам, можете попробовать команду iostat . Она тоже выводит некоторые данные о процессах, но они представлены в обобщённом виде.

Работа с iostat

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

Правда, это приводит к прокрутке выходных данных программы. Если вы занимаетесь мониторингом дисковой активности, то, возможно, вам лучше подойдёт такой вариант запуска iostat :

Если запустить утилиту с ключом -x — можно получить более подробные сведения о дисках. Флаг -z позволяет отключить вывод сведений об устройствах, на которых нет данных.

Утилита duf

Вы, вероятно, не найдёте в своей системе утилиту duf . Если это так — можете установить её с GitHub. Те же результаты, правда, можно получить, воспользовавшись df и ещё некоторыми командами, но преимущество duf заключается в том, что эта программа представляет данные в удобном для просмотра виде.

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

Вывод сведений об открытых файлах с помощью lsof

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

При использовании lsof нужно помнить о том, что шаблоны тут, по умолчанию, не работают. Поэтому следующая команда выведет лишь сведения о директории /home/alw . А вот, например, сведения о процессах, которые открыли какие-нибудь файлы в этой директории, такая команда не выведет.

Для того чтобы это изменить, можно запустить lsof с ключом -d или -D . Ключ, представленный буквой в нижнем регистре, приводит к поиску директорий и файлов на верхнем уровне. Ключ -D выполняет рекурсивный поиск. Эта команда поддерживает и много других опций, которые можно применять, например, для поиска файлов, открытых пользователем с заданным ID, или для поиска по заданному имени команды.

Дополнительный инструмент: atop

Одной из замен команды top является atop . Хотя эта команда и не нацелена исключительно на мониторинг дисковых операций, она даёт сведения о том, как процессы пользуются дисками, и, кроме того, предоставляет некоторые сводные сведения. Обычно после запуска atop в верхней части формируемого ей вывода имеется строка DSK , в которой присутствуют сведения о диске. Эти данные, по мере приближения уровня использования диска к 100%, выделяются красным цветом. Данные, выводимые в нижней части, похожи на те, что даёт команда top .

Для сортировки процессов по уровню использования дисков можно воспользоваться клавишей D . Это — полезный инструмент.

Итоги

Для того чтобы получить сведения о дисках в Linux можно применить десятки различных инструментов. Собственно говоря, нечто подобное справедливо и для решения многих других задач. Если вам интересны подробности о том, что именно выводит htop (похожие данные формируют, кроме того, top и atop ) — взгляните на этот материал.

Как вы мониторите дисковую подсистему в Linux?

Источник