высокий iowait, низкая скорость работы дисков
Но вот незадача, в последнее время на первом сервере стал безумно расти iowait % и очевидны тормоза дисковой подсистемы:
На втором сервере, даже при нагрузке в 2 раза большей, все ОК: /dev/sda: Timing buffered disk reads: 266 MB in 3.02 seconds = 88.13 MB/sec
Куда посмотреть, чтобы порешить эту проблему? Явно, что конфигурация сервера должна справляться с нагрузкой без проблем (второй сервер-то работает на ура). Конфигурация apache-а одинаковая.
ps. Тормоза начинаются при
80-100 подключениях к httpd.
высокий iowait, низкая скорость работы дисков
Сейчас вот этому первому серверу вообще туго:
/dev/sda: Timing buffered disk reads: 4 MB in 4.71 seconds = 868.87 kB/sec
Re: высокий iowait, низкая скорость работы дисков
[телепатия] У тебя деградированный RAID5 из трех дисков?
В dmesg ошибки связанные с дисковой системой есть?
высокий iowait, низкая скорость работы дисков
а дисков небось больше трех, и рейд небось железячный. да? я бы контролер поменял в первую очередь, и smartctl-ом по всем винтам.
высокий iowait, низкая скорость работы дисков
Нету там никаких RAID-ов, на каждом сервере по два диска просто примонтированные в разные точки.
высокий iowait, низкая скорость работы дисков
Нет, никаких ошибок и никакого RAID-а..
высокий iowait, низкая скорость работы дисков
Посмотри через iotop, он поподробнее информацию выдаст.
высокий iowait, низкая скорость работы дисков
А подскажите, какие параметры и где есть смысл еще посравнивать между двумя серверами. если один дохнет, а другой держит без прооблем нагрузку в 2-3 раза большую? Железо одинаковое, софт тоже, приложения идентичные
высокий iowait, низкая скорость работы дисков
Вот еще что нашлось.
Видно, что IO/BI разнится в 5 раз.
высокий iowait, низкая скорость работы дисков
PIO0? Советую проверить режимы дисков в hdparm.
высокий iowait, низкая скорость работы дисков
ну тогда надо исключить очевидное. заменить сата-шнурки к примеру
Re: высокий iowait, низкая скорость работы дисков
Сразу на двух дисках накрылись шнурки и когда менялся один из дисков, шнурок тоже менялся. Не вариант
Re: высокий iowait, низкая скорость работы дисков
Скорость работы дисков пропорциональна нагрузке создаваемой httpd. Сейчас вот 8 подключений к виртуалхосту, который на втором диске к примеру, скорость видно что уже ненормальная:
/dev/sdb: Timing buffered disk reads: 58 MB in 3.13 seconds = 18.52 MB/sec
Повторюсь, что на каждом сервере по два диска и грубо говоря на каждом есть директория одного виртуалхоста. На первом сервере начинают тормозить оба диска в зависимости и пропорционально подключениям к виртуалхостам На втором сервере все летает мухой вне зависимости от всего.
высокий iowait, низкая скорость работы дисков
Re: высокий iowait, низкая скорость работы дисков
hdparm для тормозной машины:
Заметки о 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?
Насколько я читал об iowait, для меня все еще остается загадкой.
Я знаю, что время, затраченное на то, чтобы процессор ожидал завершения операций ввода-вывода, но какие именно операции ввода-вывода точно? Я тоже не уверен, почему это так важно? Не может ли процессор сделать что-то еще, пока операция ввода-вывода завершена, а затем вернуться к обработке данных?
Также каковы правильные инструменты для диагностики того, какие процессы (ы) точно подождали IO.
И каковы способы минимизации времени ожидания ввода-вывода?
7 ответов
Я знаю, что время, затраченное на процессор ожидая операций ввода-вывода для полный, но какой IO операции точно? Я тоже Не уверен, почему это так важно? Не может процессор просто сделать что-то еще пока операция ввода-вывода завершена, и затем вернитесь к обработке данных?
Да, операционная система будет планировать запуск других процессов во время блокировки ввода-вывода. Однако внутри этого процесса, если он не использует асинхронный ввод-вывод, он не будет прогрессировать, пока не завершится какая-либо операция ввода-вывода.
И какие правильные инструменты для диагностировать, какие процессы (ы) сделали точно подождите IO.
Некоторые инструменты, которые могут вам пригодиться
И каковы способы минимизации IO время ожидания?
Старый вопрос, недавно натолкнувшийся, но чувствовал, что существующих ответов было недостаточно.
Определение IOWait & Свойства
Важность & Потенциальное заблуждение
IOWait важен, потому что часто это ключевой показатель, чтобы знать, есть ли у вас узкое место в IO. Но отсутствие iowait не обязательно означает, что ваше приложение не узкое место на IO. Рассмотрим два приложения, запущенные в системе. Если программа 1 сильно загрязнена и программа 2 является тяжелым пользователем ЦП, то процессор % user +% system может все еще быть чем-то вроде
100%, и соответственно, iowait будет показывать 0. Но это просто потому что программа 2 является интенсивной и относительно не говорит ничего о программе 1, потому что все это с точки зрения ЦП.
Инструменты для обнаружения IOWait
См. сообщения от Дэйва Чейни и Ксеркса
Уменьшение значения IOWait
Это обычно означает, что блок-устройства (то есть физические диски, а не память) слишком медленны или просто насыщены.
Я приведу несколько важных разделов (в случае, если ссылка будет мертвой), некоторые из них будут повторениями того, что уже сказали другие, но для меня, по крайней мере, они были яснее:
Каждый процессор может находиться в одном из четырех состояний: user, sys, idle, iowait.
Мне было интересно, что происходит, когда в системе есть другие процессы, готовые к запуску, пока один процесс ожидает ввода-вывода. Ниже объясняется это:
Какие операции ввода-вывода будут зависеть от ваших приложений и настроек.
Важно, так как в некоторых случаях ЦП не может получить данные или инструкции, которые необходимо продолжить. В некоторых случаях это может продолжаться, но это будет зависеть от того, какие приложения работают, что он может сделать. Если у вас есть однопоточное приложение, которое делает много доступа к диску, вам нужно будет подождать.
Чтобы минимизировать время ввода-вывода, покупать все больше и быстрее памяти, получать более быстрые диски, дефрагментировать имеющиеся у вас диски.
Если это внутреннее приложение, которое является узким местом, посмотрите, можно ли его оптимизировать для чтения в больших блоках или для ввода IO асинхронно.
vmstat также показывает, сколько блоков процесса r: количество процессов, ожидающих времени выполнения.
b: Количество процессов в режиме бесперебойного сна.
Практические рекомендации: устраняйте неполадки, используя команду ‘Top’ в Linux
Вывод команды «top»
Если в коммандной строке линукс системы вы наберете команду top, то получите табличку со следующим заголовком:
Давайте разберем значение каждой из строк.
top – 17:15:19 up 32 days, 18:24, 6 users
Здесь показана команда и текущее системное время; «время бесперебойной работы», в нашем случае это 32 дня, 18 часов и 24 минуты; наконец, указывается количество зарегистрированных в системе пользователей; в данном примере, в системе зарегистрированы 6 пользователей. Они могут быть подключены по SSH, локально, быть неактивными и т.д.
load average: 0,00, 0,01, 0,05
В этой части показывается средняя нагрузка; она может сбивать с толку, особенно на виртуальной машине/в облаке.
Первая цифра показывает среднюю нагрузку «последней минуты», или «текущую» среднюю нагрузку; вторая цифра показывает «среднюю нагрузку за 5 минут», последняя цифра – «среднюю нагрузку за 15 минут».
Средняя нагрузка – мера среднего числа процессов, ожидающих своей очереди, чтобы совершить какое-либо действие в процессоре. Как и в супермаркете, приходится стоять в очереди, дожидаясь, пока кассир уделит вам все свое внимание. Причина, по которой средняя нагрузка растет, заключается в остальной статистике и счетчиках, находящихся ниже этой линии, поэтому, если ориентироваться строго на значения средней нагрузки, можно не увидеть всей картинки полностью.
Вот пример, взятый из узла distcc:
Данный сервер, кроме того, что является средой промежуточной обработки для скриптов и хостингом инструментов командной строки облака, предоставляет также распределенную службу C компилятора различным машинам, находящимся в нашей сети, поскольку она имеет 8 процессоров, 32 ГБ оперативной памяти и тонну псевдодискового пространства. При нормальной нагрузке, среднее ее значение остается относительно низким; при выполнении java-скриптов нагрузка может вырастать в два и более раза. Однако при выполнении службы компилятора при полной нагрузке (10 выполняемых процессов при загрузке процессора, равной 95% или выше), среднее значение нагрузки составляет 0,75… Как же так получается? Попытаемся разобраться
Строка Tasks
Строка Cpu
Я разобью эту информацию на две части, в них содержится статистика, важная для нашего использования.
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni, 99.9%id,
Первые четыре величины, приведенные здесь, присутствуют на всех серверах с linux, и они привычны для большинства людей.
• %us показывает использование отдельного процессора (пользовательскими процессами, такими, как apache, mysql и т.д.) до максимального значения, составляющего 100%. Таким образом, если в четырехъядерном процессоре 1 процесс использует 100% CPU, это даст значение %us, равное 25%. Значение 12,5% для 8-ядерного процессора означает, что занято одно ядро.
• %sy означает использование CPU системой. Обычно это значение невысоко, высокие его значения могут свидетельствовать о проблеме с конфигами ядра, проблему со стороны драйвера, или целый ряд других вещей.
• %ni означает процент CPU, используемого пользовательскими процессами, на которые повлияло использование команд nice или renice, т.е. по существу их приоритет был изменен по сравнению с приоритетом по умолчанию, назначаемому планировщиком, на более высокий или низкий. При назначении какому-либо процессу команды nice, положительное число означает более низкий приоритет (1 = 1 шаг ниже нормального), а отрицательное число означает более высокий приоритет. 0 – значение по умолчанию, что означает, что решение о приоритете принимает планировщик. Можно установить, какой планировщик используется вашей системой, но это более сложная тема для следующих статей. Кроме того, любая величина в процентах, приведенная в этот статье не накладывается на величину %us, которая показывает только пользовательские процессы с невыставленным приоритетом.
• %id – результат, получающийся при вычитании трех предыдущих значений из 100,0%, и измеряющий «простаивающую» вычислительную мощность.
0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Второй набор значений связан с виртуализацией, и именно по ним мы можем точно отследить те проблемы, которые, возможно, вносят вклад в высокое значение средней нагрузки.
• %wa – iowait, процент времени (циклов, секунд), в течение которого процессор простаивал, ожидая завершения операции ввода-вывода. Когда какой-либо процесс или программа запрашивает данные, он сначала проверяет кэш процессора (в нем имеется 2 или 3 кэша), затем проверяет память и, наконец, доходит до диска. Дойдя до диска, процессу или программе обычно приходится ждать, пока поток ввода-вывода передаст информацию в оперативную память, прежде чем иметь возможность снова на нем работать. Чем медленнее диск, тем выше будет значение IO Wait % для каждого процесса. Это происходит также с процессами записи на диск, если системный буфер заполнен и его необходимо прочистить при помощи ядра – обычно это наблюдается на серверах баз данных с высокой нагрузкой. Если значение IO Wait стабильно превышает <100 / (кол-во CPU * кол-во процессов)>%, это означает, что, возможно, имеется проблема хранения, с которой необходимо разобраться. Если вы наблюдаете высокую среднюю нагрузку, прежде всего, проверьте этот параметр. Если он высок, тогда узкое место в процессах, скапливающихся на диске, а не в чем-либо еще.
• %hi означает прерывания на уровне железа; на плате электроны движутся по микросхемам предсказуемым образом. Например, когда сетевая карта получает пакет, перед передачей информации, содержащейся в пакете в процессор через ядро, она запросит прерывание в канале прерывания материнской платы. Процессор сообщает ядру, что у сетевой карты для него есть информация, а ядро имеет возможность решить, как поступить. Высокое значение времени, тратящегося на обработку прерываний на уровне железа встречается на виртуальной машине довольно редко, но по мере того, как гипервизоры предоставляют в распоряжение виртуальных машин все больше «железа», эта ситуация может измениться. Чрезвычайно высокая пропускная способность сети, использование USB, вычисления на графических процессорах, — все это может привести к росту этого параметра на величину, превышающую несколько процентов.
• %si – прерывание на уровне софта; в ядре linux версии 2.4 реализована возможность запроса прерывания программным обеспечением (приложениями), а не элементом аппаратного обеспечения или устройством (драйвером), запрашивающим прерывание в канале прерывания материнской платы; запрос обслуживается ядром посредством его обработчика прерываний. Это означает, что приложение может запросить приоритетный статус, ядро может подтвердить получение команда, а программное обеспечение будет терпеливо ждать, пока прерывание не будет обслужено. Если мы применим утилиту tcpdump к гигабитному каналу с высоким трафиком, то значение может измениться примерно на 10%, — по мере заполнения выделенной памяти tcpdump, утилита посылает зарос на прерывание, чтобы переместить данные со стека на диск, экран, или куда угодно еще.
• %st — самый важный параметр из всех в списке, по моему мнению, это IOSteal%. В виртуализированной среде множество логических серверов могут работать под одним фактическим гипервизором. Каждой виртуальной машине(VM) мы присваиваем 4-8 «виртуальных» CPU; хотя сами гипервизоры могут не иметь (кол-во VM * кол-во виртуальных CPU на одну VM). Причина этого заключается в том, что мы не перегружаем CPU использованием наших виртуальных машин, так что если мы дадим одной-двум VM возможность изредка использовать 8 процессоров, это не будет негативно влиять на весь пул в целом. Однако если виртуальными процессорами VM используется количество CPU, превышающее количество физических (или логических, в случае с гиперпотоковыми процессорами Xeon), тогда значение iosteal будет расти.
iosteal% — мера загруженности гипервизора; наличие в каком-либо пуле виртуальных машин, демонстрирующих стабильно высокое значение параметра iosteal% (более 15%) может свидетельствовать о необходимости переноса некоторых из VM в другую часть пула.
iowait% является показателем производительности диска. В системе хранения данных, поддерживаемой NetApp, у нас может не получиться решить проблему производительности без перемещения тома на менее используемый, или другой диск NetApp. В случае с локальным диском (SSD или SAS) это может означать, что в гипервизоре имеется слишком много VM, интенсивно использующих ресурсы диска, и может потребоваться перенести некоторые из этих VM в другую часть пула.
Подведем итоги:
• Средняя нагрузка, на самом деле, ни о чем не говорит.
• Параметр %userland (%us) важен для средней нагрузки, поскольку он говорит о том, что производятся вычисления. Например, mysql, займет всего один поток, поэтому при полной нагрузке будет использовать (1/кол-во виртуальных CPU, присвоенных VM). postgresql является многопоточным, и может использовать больше процессоров, если они будут выделены, – помните об этом, создавая виртуальные машины в гипервизоре, чтобы предотвратить:
• %st – iosteal% — показатель загруженности гипервизора. Создание стека из 4-х postgresql и 6 серверов tomcat под одним гипервизором может быть разумным с точки зрения бизнеса, но вам придется все время конкурировать за процессорное время.
• %wa – iowait% — показатель количества времени, которое уходит на отсылку ваших процессов на невероятно медленные диски, неважно какое решение для хранения данных вы используете. Диски, даже SSD, сравнительно медленные. Добавление ОЗУ для увеличения буфера ядра может немного смягчить проблему. ОЗУ дешевле диска, если учесть, насколько молниеносно она работает по сравнению с ним.
Дополнительные команды
iostat
Если вы столкнулись с высокими значениями параметров iowait или iosteal, можно с точностью отследить, какой диск является этому причиной, при помощи команды iostat. Запускается она таким образом:
Более подробно, см. руководство по iostat. Разбивка, выводимая каждую секунду, с каких и на какие диски идет чтение/ запись, а также все значения iosteal или iowait, связанные с доступом к этим дискам.
htop
Команда по использованию CPU и процессов на системе Linux. Он не показывает виртуальную статистику, но отображает дерево процессов, а также разбивку каждого процессора в системе, его использование; кроме того, он показывает статистику свопинга и памяти, позволяющую отследить неприятные утечки памяти, раскрашивая все это симпатичными цветами. По моему мнению, этот пакет должен быть обязательным для всех VM.
Почему растет iowait?
Есть сервер на digitalocean на котором стоит приложение под докером. Nginx, postgres, php
Каждый день ровно в 5 утра начинаются сильные проблемы с iowait продолжительностью примерно 30 минут. Доходит до 40% из-за чего лагает все приложение.
Проверил уже несколько раз все приложение никаких задач в это время нет и каких-то предположений кто может напрягать в это время диск не нашел.
При том такая же проблема есть и на 2м сервере ровно в это же время и столько же по продолжительности, но там iowait растет до 20%, на остальных серверах все хорошо.
Грузит вроде как бд, но никакой кучи запросов в это время нет и никакие команды не выполняются.
До лагов: 
Во время: 
Простой 11 комментариев
The writer a.k.a. background writer process
Note that we assume that the high level concept of “checkpoints” together with the checkpointer process and its parameters are already familiar to you (as it’s way more impactful compared to the writers). When not, I’d recommend digging into Postgres documentation here.
So to the writer. Introductory sentence in the documentation tells us:
There is a separate server process called the background writer, whose function is to issue writes of “dirty” (new or modified) shared buffers. It writes shared buffers so server processes handling user queries seldom or never need to wait for a write to occur. However, the background writer does cause a net overall increase in I/O load, because while a repeatedly-dirtied page might otherwise be written only once per checkpoint interval, the background writer might write it several times as it is dirtied in the same interval. …
In short – the writer moves some of the changed data (dirty buffers) already to the disk in the background, so that checkpoint process, happening at regular intervals, would have less work to do. All of this with the point that in the end user/application queries wouldn’t need to suffer too much when checkpointer kicks in with its heavy IO requirements, when there are lots of buffers to be processed or checkpoint_completion_target is set too small. All this is relevant of course only when we’re running a relatively busy database – for idling databases it wouldn’t be a problem at all.
