Нагрузка на диски в 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.

Источник

Политика управления частотой процессора «ondemand» и iowait в Ubuntu

В современных версиях Ubuntu по умолчанию включена политика управления частотой процессора «ondemand». Эта штука весьма полезна в плане энергосбережения, поскольку устанавливает частоту процессора на минимально возможную, когда нагрузка на процессор невелика.

Однако, недавно я заметил, что у неё есть один недостаток: «ondemand» воспринимает нагрузку на процессор, вызванную операциями ввода-вывода, как «idle». Что это значит? Это значит, что при загрузке процессора операциями ввода-вывода частота процессора зачастую остаётся на пониженном уровне, что создаёт проблемы, если ваша система страдает от печально известного линуксового бага с iowait.

Бороться с таким поведением «ondemand» можно двумя способами.

Первый вариант — отключить энергосберегающий режим процессора. Например, исправив скрипт, который его включает. Он скрывается под вполне логичным именем «ondemand» и располагается в /etc/init.d . Если исправить в этом файле строку

, то процессор будет постоянно работать на максимальной частоте.

Второй вариант — включить для «ondemand» режим, в котором он не будет игнорировать iowait. Это управляется параметром в /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy . Для этого я написал маленький init-скрипт:

После этого скрипт сохраняется в файл /etc/init.d/io-is-busy , делается исполняемым и прописывается в системе командой sudo update-rc.d io-is-busy defaults 99 99 .

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

Источник

Кто-нибудь может объяснить точно, что такое IOWait?

Столько, сколько я прочитал о Айовите, это все еще загадка для меня.

Я знаю, что это время, потраченное процессором на ожидание завершения операций ввода-вывода, но какой именно тип операций ввода-вывода? В чем я тоже не уверен, почему это так важно? Разве процессор не может просто сделать что-то еще, когда операция ввода-вывода завершится, и затем вернуться к обработке данных?

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

И как можно минимизировать время ожидания ввода-вывода?

Я знаю, что это время, потраченное процессором на ожидание завершения операций ввода-вывода, но какой именно тип операций ввода-вывода? В чем я тоже не уверен, почему это так важно? Разве процессор не может просто сделать что-то еще, когда операция ввода-вывода завершится, и затем вернуться к обработке данных?

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

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

Некоторые инструменты, которые вы можете найти полезными

• iostat , чтобы следить за временем обслуживания ваших дисков
• iotop (если ваше ядро ​​поддерживает это), чтобы отслеживать разбивку запросов ввода-вывода на процесс
• strace , чтобы посмотреть на фактические операции, выпущенные процессом

И как можно минимизировать время ожидания ввода-вывода?

• убедитесь, что у вас есть свободная физическая память, чтобы ОС могла кешировать дисковые блоки в памяти
• держите дисковое пространство файловой системы ниже 80%, чтобы избежать чрезмерной фрагментации
• настроить вашу файловую систему
• использовать контроллер массива с батарейным питанием
• выбирайте хороший размер буфера при выполнении операций ввода-вывода

Старый вопрос, недавно столкнулся, но чувствовал, что существующих ответов было недостаточно.

IOWait определение и свойства

IOWait (обычно помеченный %wa сверху) является подкатегорией бездействия ( %idle обычно выражается как все бездействия, кроме определенных подкатегорий), то есть процессор ничего не делает. Поэтому, пока есть другой процесс, который процессор может обрабатывать, он будет это делать. Кроме того, время простоя, пользователь, система, iowait и т. Д. Являются измерением по отношению к процессору. Другими словами, вы можете думать о iowait как о бездействии, вызванном ожиданием io.

Точно, iowait — это время, потраченное на получение и обработку аппаратных прерываний в процентах от тактов процессора. Программные прерывания обычно помечаются отдельно как %si .

Важность и потенциальное заблуждение

IOWait важен, потому что он часто является ключевым показателем, чтобы узнать, нет ли у вас узких мест в IO. Но отсутствие iowait не обязательно означает, что ваше приложение не является узким местом при IO. Рассмотрим два приложения, работающие в системе. Если программа 1 сильно затруднена, а программа 2 является интенсивным пользователем %user + %system ЦП, загрузка ЦП все равно может составлять

100% и, соответственно, iowait будет показывать 0. Но это только потому, что программа 2 интенсивна и, по-видимому, ничего не говорит о программа 1, потому что все это с точки зрения процессора.

Инструменты для обнаружения IOWait

Смотрите посты Дейва Чейни и Ксеркс

Но и простое top покажет в %wa .

Сокращение IOWait

Кроме того, поскольку мы сейчас почти вступаем в 2013 год, в дополнение к тому, что говорили другие, доступны недорогие устройства хранения ввода-вывода, а именно SSD. Твердотельные накопители потрясающие .

iowait время, в течение которого процессор / процессоры ожидают (то есть находится в состоянии простоя и ничего не делает ), в течение которого фактически были невыполненные запросы дискового ввода-вывода.

Обычно это означает, что блочные устройства (то есть физические диски, а не память) слишком медленные или просто насыщены.

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

• sar (из sysstat пакета, доступного на большинстве машин * nix)
• iostat
• sarface (интерфейс к sar )

Я нашел объяснение и примеры по этой ссылке очень полезными: что именно означает «Айоваит»? , Кстати, для полноты, ввод-вывод здесь относится к дисковому вводу-выводу, но может также включать в себя ввод-вывод на подключенном к сети диске (например, nfs), как объяснено в этом другом посте .

Я процитирую несколько важных разделов (в случае, если ссылка не работает), некоторые из них будут повторением того, что уже сказали другие, но мне, по крайней мере, это было более понятно:

Подводя итог, можно сказать, что в одном предложении «iowait» — это процент времени, в течение которого центральный процессор не используется, и выполняется хотя бы один ввод / вывод.

Каждый процессор может находиться в одном из четырех состояний: пользователь, sys, idle, iowait.

Мне было интересно, что происходит, когда в системе есть другие процессы, готовые к запуску, пока один процесс ожидает ввода-вывода. Ниже это объясняется:

Если процессор простаивает, ядро ​​затем определяет, выполняется ли в настоящее время хотя бы один ввод-вывод на локальном диске или на удаленно смонтированном диске (NFS), который был инициирован с этого процессора. Если есть, то счетчик ‘iowait’ увеличивается на единицу. Если нет ввода-вывода, который был запущен из этого ЦП, счетчик «ожидания» увеличивается на единицу.

Допустим, на процессоре работают две программы. Одним из них является чтение программы «dd» с диска. Другая — это программа, которая не выполняет ввод-вывод, но тратит 100% своего времени на вычислительную работу. Теперь предположим, что есть проблема с подсистемой ввода-вывода и что физические операции ввода-вывода занимают секунду, чтобы завершиться. Всякий раз, когда программа dd спит в ожидании завершения ввода-вывода, другая программа может работать на этом процессоре. Когда происходит прерывание часов, всегда будет программа, работающая либо в пользовательском, либо в системном режиме. Таким образом, значения% idle и% iowait будут равны 0. Даже если iowait равен 0, это не означает, что нет проблемы ввода-вывода, потому что, очевидно, существует одна, если физические операции ввода-вывода занимают секунду для завершения.

Полный текст стоит прочитать. Вот зеркало этой страницы , на случай, если оно исчезнет.

Источник

Системная нагрузка и %iowait

Системная нагрузка – это показатель того, какая нагрузка ложится на микропроцессор(-ы).

Как правило, необходимо, чтобы он держался на уровне ниже 1,0 на микропроцессор или ядро в Вашей системе.

Это значит, что если у Вас четырехъядерная система, как в машине, которую я анализирую, необходимо держать показатель нагрузки на систему ниже 4,0.

%iowait

%iowait – показатель, означающий процентное соотношение времени процессора, потраченное на ожидание ввода/вывода.

Высокий %iowait говорит о том, что Ваша система ограничена возможностями дисковой памяти, выполняя множество операций дискового ввода-вывода, что приводит к замедлению работы системы.

К примеру, если Вашему серверу требовалось бы возвращать 100 или более файлов на каждый запрос, вполне вероятно, это стало бы причиной значительного роста времени %iowait, что означало бы, что диск является узким местом.

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

Два хороших показателя производительности системы – это средняя нагрузка и %iowait. Среднюю нагрузку можно посмотреть с помощью утилиты top, а %iowait — с помощью команды iostat.

Необходимо следить и за top, и за iostat во время теста с длительной нагрузкой, чтобы увидеть, как будут меняться показатели. Давайте запустим top и iostat в отдельных терминалах.

Источник