Evaluating the CPU I/O wait on Linux
You need to be careful when evaluating these figures.
- IOWait is related, but not necessarily linearly correlated with disk activity.
- The number of CPUs you have affects your percentage.
- A high IOWait (depending on your application) does not necessarily indicate a problem for you. Alternatively a small IOWait may translate into a problem for you. It basically boils down to what task is waiting.
IOWait in this context is the measure of time over a given period that a CPU (or all CPUS) spent idle because all runnable tasks were waiting for a IO operation to be fulfilled.
In your example, if you have 20 CPUs, with one task really hammering the disk, this task is (in effect) spending 100% of its time in IOWait, subsequently the CPU that this task runs on spends almost 100% of its time in IOWait. However, if 19 other CPUs are effectively idle and not utilizing this disk, they report 0% IOWait. This results in an averaged IOWait percentage of 5%, when in fact if you were to peek at your disk utilization this could report 100%. If the application waiting on disk is critical to you — this 5% is somewhat misleading because the task in the bottleneck is seeing likely much higher performance issues than going 5% slow.
there are almost as many CPU processes waiting than working? (=> bad)
Probably, remember for the most part CPUs run tasks and tasks are what request IO. If two separate tasks are busy querying the same disk on two separate CPUs, this will put both CPUs at 100% IOWait (and in the 20 CPU example a 10% overall average IOWait).
Basically if you have a lot of tasks that request IO, especially from the same disk, plus that disk is 100% utilized (see iostat -mtx ) then this is bad.
the working processeses are waiting 5,0% of their execution plan? (=> ok in this case)
No. The working processes are almost certainly waiting full-time for IO. It’s just the average report case («the other CPUs are not busy») fudges the percentage or the fact that the CPU has many tasks to run, of which many don’t need to do IO.
As a general rule, on a multi-CPU system, an IOWait percentage which is equal to the number of CPUs you have divided by a 100 is probably something to investigate.
See above. But note that applications that do very heavy writing are throttled (stop using writeback, start writing directly to disk). This causes those tasks to produce high IOWait whilst other tasks on the same CPU writing to the same disk would not. So exceptions do exist.
Also note if you have 1 CPU dedicated to running 2 tasks, one is a heavy IO read/writer and the other is a heavy CPU user, then the CPU will report 50% IOWait in this case, if you have 10 tasks like this it would be 10% IOWait (and a horrific load), so the number can be reported much lower than what might actually be a problem.
I think you really need to take a look at iostat -mtx to get some disk utilization metrics, and pidstat -d to get some per-process metrics, then consider whether or not the applications hitting those disks in that way are likely to cause a problem, or other potential applications that hit those disks being likely to cause a problem.
CPU metrics really act as indicators to underlying issues, they are general so understanding where they may be too general is a good thing.
IOWAIT в Linux
Высокий 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 это часто делается командой:
sudo apt-get install sysstatа на Centos это можно сделать командой
Точной командой, которую я рекомендую, будет «iostat -mxy 10» — затем подождите 10 секунд. Каждые 10 секунд она будет выдавать среднее значение дисковой активности за этот 10-секундный период. Флаг «m» дает результаты в мегабайтах, «x» дает расширенные результаты, а флаг «y» опускает первый результат (который обычно является средним результатом с момента загрузки системы). «10» означает показывать результаты каждые 10 секунд.
Из всего вышесказанного наиболее полезным значением, на которое следует обратить внимание, является %util — процент использования. Это процент времени, в течение которого диск активно обслуживает запросы. Если этот показатель постоянно очень высок, скажем, более 50% большую часть времени, то да, скорее всего, сервер работает медленно из-за чрезмерного обращения к диску.
Даже это значение может быть несколько обманчивым для NVMe SSD, которые могут обрабатывать множество одновременных подключений, но это определенно хорошая отправная точка, и оно очень подходит для обычных жестких дисков. Если %util постоянно ниже 30% большую часть времени, скорее всего, у вас нет проблем с дисковым вводом-выводом.
Если вы сомневаетесь, вы также можете посмотреть на r_await и w_await columsn — среднее количество времени в миллисекундах, которое ожидает запрос на чтение или запись на диск, прежде чем он будет обработан — чтобы понять, способен ли диск обрабатывать запросы своевременно. Значение менее 10 мс для SSD или 100 мс для жестких дисков обычно не вызывает беспокойства, а меньшее значение лучше.
Надеюсь, эта статья дала вам представление о том, стоит ли беспокоиться о дисковой производительности вашего сервера, поскольку она связана со статистикой iowait и util%.
Похожие записи:
Заметки о Unix: проблема 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-систем?
