Cpu iowait time


проблема iowait и многопроцессорные системы / Хабр

В разных Unix-системах уже давно имеется показатель iowait. Я, правда, не могу найти систему, в которой этот показатель появился. Это — не 4.x BSD, поэтому iowait, возможно, добрался до современных систем через System V и sar. Традиционным, стандартным определением iowait является время, которое система проводит в бездействии, когда в ней имеется хотя бы один процесс, ожидающий окончания операции дискового ввода-вывода. Вместо того чтобы относить это время к категории idle (простой процессора) (когда процессорное время делится на три категории — user, system и idle), в некоторых Unix-системах это время стали относить к новой категории — iowait.



(К моему удивлению оказалось, что понятия «iowait», похоже, нет ни в одной *BSD-системе. Там используется старая схема user-system-idle и детализация системного времени. Iowait имеется в Linux и в Solaris/Illumos, этот показатель, если верить результатам беглого просмотра справки, есть ещё в HP-UX и в AIX. )

Вышеприведённое определение iowait выглядит совершенно осмысленным и понятным на однопроцессорной машине, где система не может одновременно и пребывать в состоянии бездействия, ожидая, когда процесс завершит операцию ввода-вывода, и выполнять другой процесс. Но в наши дни практически все компьютеры представляют собой многопроцессорные «SMP», а в многопроцессорной среде способ определения показателя iowait уже далеко не так прост, так как там нет чёткого разделения между «выполняющимся кодом» и «кодом, остановленным в ожидании завершения операции ввода-вывода». В многопроцессорных системах некоторые процессоры могут быть заняты выполнением кода, а некоторые процессы могут быть заблокированы в ожидании результатов операций ввода-вывода. Если операции ввода-вывода, выполняемые такими процессами, завершаются мгновенно, они, на самом деле, могут выполняться на процессорах, которые в настоящий момент простаивают. Но, в то же время, система занята некоей работой вместо того, чтобы, полностью остановившись, ожидать завершения операции ввода-вывода (а в однопроцессорной системе показатель iowait рассчитывается именно на основании времени, когда система находится в подобном состоянии).

На вопрос о том, что представляет собой iowait в многопроцессорной Unix-системе, можно дать множество правдоподобных ответов. Они могут быть простыми, сложными, или применимыми в некоей конкретной ситуации. Но вне зависимости от того, как именно работает Unix, система должна выдать некий результат (и, в идеале, алгоритм получения этого результата должен быть задокументирован). При этом нет гарантии того, что механизм нахождения показателя iowait будет одним и тем же в разных Unix-системах. Если вы собираетесь серьёзно пользоваться iowait — то вам может понадобиться выяснить то, как именно ваша Unix-система определяет этот показатель в многопроцессорной среде.

(Поиск ответа на вопрос о том, что такое iowait, усложняется в том случае, если используемая вами Unix-система при расчёте iowait ориентируется на отдельные процессоры, как часто бывает с категориями user, system и idle. Дело в том, что обычно ожидание результатов ввода-вывода не связано неким естественным образом с каким-то конкретным процессором. Похоже, что в illumos, если учесть то немногое, что об этом сказано в справке по mpstat, показатель iowait не рассматривается как нечто, относящееся к отдельным процессорам. А справка по sar(1) указывает на то, что в этой системе использован более общий подход к пониманию iowait.)

Пользуетесь ли вы показателем iowait при анализе производительности своих Unix-систем?

IOWAIT в Linux - General Software

Высокий IOWAIT может стать настоящей проблемой в linux, заставляя ваш сервер работать с перебоями. Вопрос в том, насколько высокий уровень является слишком высоким? Когда стоит беспокоиться?

 

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

Что такое IOWAIT? Как показывает "wa%" в команде "top", iowait - это процент времени, в течение которого центральный процессор ожидает обращения к диску, прежде чем он сможет выполнить полезную работу. Во времена одноядерных серверов с одним процессором этот процент был довольно значимым сам по себе. Значение 25% означало, что система ожидает обращения к диску 1/4 часть времени. Теперь, с многоядерными серверами и гиперпоточностью, это процентное значение не всегда много значит. Например, на четырехъядерной системе с гиперпоточностью значение wa% 12,5% может означать, что одно ядро процессора все время ожидает диск - потенциально серьезная проблема, влияющая на производительность сервера, - или это может означать, что все ядра процессора ожидают 1/8 часть времени - гораздо менее серьезная проблема.

Поэтому на современных серверах значение IOWAIT само по себе мало что значит. Если вы видите, что оно увеличивается больше, чем вам хотелось бы, разумно будет посмотреть на другие значения, чтобы определить, есть ли реальная проблема или нет. Таким образом, в наши дни IOWAIT больше привлекает ваше внимание к поиску реальных проблем, а не говорит о том, есть ли они или нет.

На изображении примера вы можете увидеть "0. 0 wa", что означает 0,0% iowait. Безусловно, даже с учетом уже упомянутых предостережений, это указывает на то, что iowait не является проблемой. Но что, если это значение выше?

Учитывая проблемы с iowait, на что следует обратить внимание? В большинстве версий linux команда "iostat" дает гораздо лучшее представление о здоровье и производительности вашей дисковой системы. Если у вас нет команды "iostat", вам нужно установить пакет "sysstat" - на Ubuntu это часто делается командой "apt-get install sysstat", а на Centos это можно сделать командой "yum install sysstat".

Точной командой, которую я рекомендую, будет "iostat -mxy 10" - затем подождите 10 секунд. Каждые 10 секунд она будет выдавать среднее значение дисковой активности за этот 10-секундный период. Флаг "m" дает результаты в мегабайтах, "x" дает расширенные результаты, а флаг "y" опускает первый результат (который обычно является средним результатом с момента загрузки системы). "10" означает показывать результаты каждые 10 секунд.

iostat -mxy 10

Из всего вышесказанного наиболее полезным значением, на которое следует обратить внимание, является %util - процент использования. Это процент времени, в течение которого диск активно обслуживает запросы. Если этот показатель постоянно очень высок, скажем, более 50% большую часть времени, то да, скорее всего, сервер работает медленно из-за чрезмерного обращения к диску.

Даже это значение может быть несколько обманчивым для NVMe SSD, которые могут обрабатывать множество одновременных подключений, но это определенно хорошая отправная точка, и оно очень подходит для обычных жестких дисков. Если %util постоянно ниже 30% большую часть времени, скорее всего, у вас нет проблем с дисковым вводом-выводом.

Если вы сомневаетесь, вы также можете посмотреть на r_await и w_await columsn - среднее количество времени в миллисекундах, которое ожидает запрос на чтение или запись на диск, прежде чем он будет обработан - чтобы понять, способен ли диск обрабатывать запросы своевременно. Значение менее 10 мс для SSD или 100 мс для жестких дисков обычно не вызывает беспокойства, а меньшее значение лучше.

Надеюсь, эта статья дала вам представление о том, стоит ли беспокоиться о дисковой производительности вашего сервера, поскольку она связана со статистикой iowait и util%.

Что такое iowait и как он влияет на производительность Linux?

5 августа 2022 г. by Hayden James , in Blog Linux

I/O wait или iowait , wait , wa , %iowait или wait% часто отображается инструментами мониторинга системы Linux из командной строки, такими как top, sar, atop и другими. Сам по себе это один из многих показателей производительности, которые дают нам представление о производительности системы Linux.

Ожидание ввода-вывода появилось в недавнем обсуждении с новым клиентом. Во время нашего обращения в службу поддержки они сообщили о скачках нагрузки от 60 до 80 в своей системе с 32 ядрами ЦП. Это приводило к медленной загрузке страниц, тайм-аутам и периодическим отключениям. Причина? На узкое место ввода-вывода в системе хранения изначально намекал постоянно высокий iowait, а позже это подтвердилось дополнительным исследованием.

Что такое ожидание ввода/вывода? Как ожидание ввода-вывода влияет на производительность сервера Linux? Как мы можем отслеживать и уменьшать проблемы, связанные с ожиданием ввода-вывода? Продолжайте читать, чтобы получить ответы на эти вопросы.

 

Что такое ожидание ввода/вывода?

Ожидание ввода-вывода

применяется к Unix и всем системам на базе Unix, включая macOS, FreeBSD, Solaris и Linux.

Ожидание ввода-вывода (iowait) — это процент времени, в течение которого ЦП (или ЦП) простаивал, в течение которого система имела ожидающие запросы дискового ввода-вывода. (Источник: man sar ) На справочной странице top дается простое объяснение: «Ожидание ввода-вывода = время ожидания завершения ввода-вывода». Другими словами, наличие ожидания ввода-вывода говорит нам о том, что система простаивает, когда она могла бы обрабатывать необработанные запросы.

«iowait показывает процент времени, в течение которого ЦП или ЦП простаивали, в течение которого система имела необработанный запрос дискового ввода-вывода». –   справочная страница iostat.

При использовании Linux top и других инструментов вы заметите, что ЦП (и его ядра) работают в следующих состояниях: us (пользователь), sy (система), id (ожидание), ni (хорошо), si (программные прерывания), hi (аппаратные прерывания), st (кражи) и wa (подождите). Из них значения пользователя, системы, простоя и ожидания должны составлять в сумме 100 %. Обратите внимание, что «ожидание» и «ожидание» — это не одно и то же. «Простой» ЦП означает, что рабочая нагрузка отсутствует, в то время как, с другой стороны, «ожидание»  (iowait) указывает, что ЦП ожидает в состоянии простоя для невыполненных запросов.

Если ЦП простаивает, ядро ​​​​выявит все ожидающие запросы ввода-вывода (например, SSD или NFS), исходящие от ЦП. Если есть, то увеличивается счетчик iowait. Если ничего не ожидается, счетчик простоя увеличивается.

 

Ожидание ввода-вывода и производительность сервера Linux

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

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

Например, серверное хранилище (SSD, NVMe, NFS и т. д.) почти всегда работает медленнее, чем производительность процессора. Из-за этого ожидание ввода-вывода может вводить в заблуждение, особенно когда речь идет о случайных рабочих нагрузках чтения/записи. Это связано с тем, что iowait измеряет только производительность ЦП, а не операции ввода-вывода хранилища.

Хотя iowait указывает, что ЦП может справиться с большей рабочей нагрузкой, в зависимости от рабочей нагрузки вашего сервера и того, как нагрузка выполняет вычисления или использует ввод-вывод хранилища, не всегда возможно решить проблему ожидания ввода-вывода. Или невозможно достичь околонулевого значения.

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

Например, если вы видите низкое значение iowait от 1 до 4 процентов, а затем повышаете производительность ЦП до двукратного увеличения, значение iowait также увеличится. В 2 раза более быстрый ЦП при той же производительности хранилища = ~ в 2 раза больше времени ожидания. Вы захотите рассмотреть свою рабочую нагрузку, чтобы определить, на какое оборудование вы должны обратить внимание в первую очередь.

 

Мониторинг и снижение проблем, связанных с ожиданием ввода-вывода

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

  • поверх — запустите с параметром -d или нажмите d , чтобы переключить представление статистики диска.
  • iostat — попробуйте с параметрами -xm 2 для расширенной статистики в мегабайтах и ​​с двухсекундными интервалами.
  • iotop  – верхний монитор ввода-вывода. Попробуйте с -oPa опции для отображения накопленного ввода/вывода только активных процессов.
  • ps — используйте auxf , тогда в столбце «STAT» «D» обычно указывает iowait диска.
  • strace  – просмотреть фактические операции, выполненные процессом. Прочитайте справочную страницу strace .
  • lsof — после того, как вы определили ответственный процесс, используйте -p [PID] , чтобы найти конкретные файлы.

Снижение проблем, связанных с ожиданием ввода-вывода

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

  • Оптимизируйте код своего приложения и запросы к базе данных. Это может иметь большое значение для снижения частоты чтения/записи диска. Это должен быть ваш первый подход, потому что чем эффективнее ваше приложение, тем меньше вам придется тратить на оборудование в долгосрочной перспективе. См. также: 100 Мониторинг производительности приложений (APM) и решения для наблюдения .
  • Поддерживайте актуальность версий системы Linux и программного обеспечения. Это не только лучше для безопасности, но чаще всего последние поддерживаемые версии предлагают заметные улучшения производительности, будь то Nginx, Node.js, PHP, Python или MySQL.
  • Убедитесь, что у вас есть свободная память. Достаточно свободной памяти, чтобы около половины памяти сервера использовалось для буферов в памяти и кеша, а не для подкачки и подкачки на диск. Конечно, это соотношение будет разным в каждом конкретном случае. Поэтому убедитесь, что вы не выполняете подкачку, а нагрузка на кэш ядра не высока из-за нехватки свободной памяти.
  • Настройте свою систему, устройства хранения и ядро ​​Linux, чтобы увеличить производительность и срок службы хранилища.
  • Наконец, если ничего не помогает: обновите устройства хранения данных до более быстрых SSD, NVMe или других устройств хранения данных с высокой пропускной способностью.

 

Заключение

Статистика iowait — это полезная статистика производительности для мониторинга состояния использования ЦП. Он уведомляет системного администратора, когда ЦП простаивает и может выполнять дополнительные вычисления. Затем мы можем использовать инструменты наблюдения, сравнительного анализа и отслеживания, такие как перечисленные выше, чтобы составить полную картину общей производительности ввода-вывода системы. Ваша главная цель должна состоять в том, чтобы устранить любые iowait, непосредственно возникающие в результате ожидания на диске, в NFS или других операциях ввода-вывода, связанных с хранилищем.

 

Опубликовано: 19 августа 2020 г. | Последнее обновление: 28 января 2022 г.

Метки: apm, память, производительность, сервер, ssd, системные администраторы

Оптимизация

— Оценка ожидания ввода-вывода ЦП в Linux

Вы должны быть осторожны при оценке этих цифр.

  1. IOWait связан, но не обязательно линейно коррелирует с активностью диска.
  2. Количество процессоров, которые у вас есть, влияет на ваш процент.
  3. Высокий IOWait (в зависимости от вашего приложения) не обязательно указывает на проблему. В качестве альтернативы небольшой IOWait может превратиться в проблему для вас. В основном это сводится к тому, какая задача ждет.

IOWait в данном контексте — это мера времени за заданный период времени, в течение которого ЦП (или все ЦП) простаивали, поскольку все выполняемые задачи ожидали выполнения операции ввода-вывода.

В вашем примере, если у вас есть 20 ЦП, и одна задача действительно забивает диск, эта задача (фактически) тратит 100% своего времени в IOWait, впоследствии ЦП, на котором выполняется эта задача, тратит почти 100% своего времени. время в IOWait. Однако если 19другие ЦП фактически бездействуют и не используют этот диск, они сообщают об 0% IOWait. Это приводит к среднему проценту IOWait, равному 5%, тогда как на самом деле, если бы вы посмотрели на использование вашего диска, это могло бы сообщить 100%. Если приложение, ожидающее на диске, имеет для вас решающее значение — эти 5% несколько вводят в заблуждение, потому что задача в узком месте, вероятно, испытывает гораздо более высокие проблемы с производительностью, чем медленная на 5%.

ожидающих процессов ЦП почти столько же, сколько работающих? (=> плохо)

Наверное, помните, что по большей части процессоры запускают задачи, а задачи запрашивают ввод-вывод. Если две отдельные задачи заняты запросом одного и того же диска на двух разных ЦП, это приведет к тому, что оба ЦП будут работать на 100 % IOWait (а в примере с 20 ЦП — на 10 % от общего среднего IOWait).

По сути, если у вас много задач, требующих ввода-вывода, особенно с одного и того же диска, плюс этот диск используется на 100% (см. iostat -mtx ), то это плохо.

рабочие процессы ожидают 5,0% своего плана выполнения? (=> нормально в этом случае)

Нет. Рабочие процессы почти наверняка постоянно ожидают IO. Это просто случай среднего отчета («другие ЦП не заняты») искажает процент или тот факт, что ЦП выполняет много задач, многим из которых не нужно выполнять ввод-вывод.

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

что-то еще

См. выше. Но обратите внимание, что приложения, которые выполняют очень интенсивную запись, регулируются (прекратите использовать обратную запись, начните запись непосредственно на диск). Это приводит к тому, что эти задачи производят высокий IOWait, в то время как другие задачи на том же ЦП, записывающие на тот же диск, не будут. Так что исключения действительно существуют.

Также обратите внимание, что если у вас есть 1 ЦП, выделенный для выполнения 2 задач, один из которых является интенсивным чтением/записью ввода-вывода, а другой является интенсивным пользователем ЦП, то в этом случае ЦП сообщит о 50% IOWait, если у вас есть 10 задач, таких как это будет 10% IOWait (и ужасная нагрузка), поэтому число может быть намного меньше, чем то, что может быть проблемой.


Learn more

Только новые статьи

Введите свой e-mail

Видео-курс

Blender для новичков

Ваше имя:Ваш E-Mail: