Iowait linux какой процесс
Обновлено: 04.07.2024
Насколько я читал об iowait, для меня все еще остается загадкой.
Я знаю, что время, затраченное на то, чтобы процессор ожидал завершения операций ввода-вывода, но какие именно операции ввода-вывода точно? Я тоже не уверен, почему это так важно? Не может ли процессор сделать что-то еще, пока операция ввода-вывода завершена, а затем вернуться к обработке данных?
Также каковы правильные инструменты для диагностики того, какие процессы (ы) точно подождали IO.
И каковы способы минимизации времени ожидания ввода-вывода?
Я знаю, что время, затраченное на процессор ожидая операций ввода-вывода для полный, но какой IO операции точно? Я тоже Не уверен, почему это так важно? Не может процессор просто сделать что-то еще пока операция ввода-вывода завершена, и затем вернитесь к обработке данных?
Да, операционная система будет планировать запуск других процессов во время блокировки ввода-вывода. Однако внутри этого процесса, если он не использует асинхронный ввод-вывод, он не будет прогрессировать, пока не завершится какая-либо операция ввода-вывода.
И какие правильные инструменты для диагностировать, какие процессы (ы) сделали точно подождите IO.
Некоторые инструменты, которые могут вам пригодиться
- iostat , чтобы отслеживать время обслуживания ваших дисков.
- iotop (если ваше ядро его поддерживает), чтобы отслеживать разбивку IO-запросов на процесс
- strace , чтобы посмотреть фактические операции, выданные процессом
И каковы способы минимизации IO время ожидания?
- убедитесь, что у вас есть свободная физическая память, поэтому ОС может кэшировать блоки диска в памяти
- сохраните дисковое пространство вашей файловой системы ниже 80%, чтобы избежать чрезмерной фрагментации.
- настроить вашу файловую систему
- использовать контроллер с поддержкой батареи.
- выберите хорошие размеры буфера при выполнении операций io
IOWait (обычно помеченный как % wa в верхней части) является подкатегорией idle ( % idle обычно выражается как все бездействующие, кроме определенных подкатегорий), что означает CPU ничего не делает. Поэтому, если есть другой процесс, который процессор может обрабатывать, он сделает это. Кроме того, простой, пользовательский, системный, iowait и т. Д. - это измерение по отношению к процессору. Другими словами, вы можете думать о iowait как о простоях, вызванном ожиданием io.
Точно, iowait - это время, потраченное на получение и обработку аппаратных прерываний в процентах от тиков процессора. Программные прерывания обычно выделяются отдельно как % si .
Важность & Потенциальное заблуждение
IOWait важен, потому что часто это ключевой показатель, чтобы знать, есть ли у вас узкое место в IO. Но отсутствие iowait не обязательно означает, что ваше приложение не узкое место на IO. Рассмотрим два приложения, запущенные в системе. Если программа 1 сильно загрязнена и программа 2 является тяжелым пользователем ЦП, то процессор % user +% system может все еще быть чем-то вроде
100%, и соответственно, iowait будет показывать 0. Но это просто потому что программа 2 является интенсивной и относительно не говорит ничего о программе 1, потому что все это с точки зрения ЦП.
Но и простой top будет отображаться в % wa .
Кроме того, поскольку мы сейчас почти вступаем в 2013 году, в дополнение к тому, что говорят другие, выбор просто потрясающих устройств хранения IO является доступным, а именно SSD. SSD - потрясающие .
iowait - время ожидания процессора /процессоров (т. е. находится в состоянии бездействия и ничего ), во время которого fact был выдающимися запросами ввода-вывода диска.
Это обычно означает, что блок-устройства (то есть физические диски, а не память) слишком медленны или просто насыщены.
Таким образом, вы должны заметить, что если вы видите среднее значение средней нагрузки в вашей системе и обратите внимание на то, что большинство из них на самом деле связано с ожиданием ввода-вывода, это не обязательно означает, что ваша система находится в затруднении - и это происходит, когда вашей машине просто нечего делать, кроме процессов, связанных с I /O (т.е. процессов, которые делают больше ввода-вывода, чем что-либо еще (системные вызовы, не связанные с I /O)). Это также должно быть очевидно из того факта, что все, что вы делаете в системе, все еще очень отзывчивое.
- sar (из пакета sysstat , доступного на большинстве машин * nix)
- IOSTAT
- sarface (front-end для sar )
Я нашел объяснение и примеры из этой ссылки очень полезными: Что такое «iowait»? . BTW, для полноты, здесь ввод-вывод относится к дисковым ввода-выводам, но также может включать ввод-вывод на сетевом диске (например, nfs), как описано в этот другой пост .
Я приведу несколько важных разделов (в случае, если ссылка будет мертвой), некоторые из них будут повторениями того, что уже сказали другие, но для меня, по крайней мере, они были яснее:
Подводя итог в одном предложении, «iowait» - это процент времени CPU находится в режиме ожидания. И есть хотя бы один ввод-вывод.
Каждый процессор может находиться в одном из четырех состояний: user, sys, idle, iowait.
Мне было интересно, что происходит, когда в системе есть другие процессы, готовые к запуску, пока один процесс ожидает ввода-вывода. Ниже объясняется это:
Если CPU находится в режиме ожидания, ядро затем определяет, есть ли хотя бы один ввод-вывод, который выполняется в настоящее время на локальном диске или удаленно (NFS), который был инициирован с этого CPU. Если здесь , то счетчик «iowait» увеличивается на единицу. Если нет Выполняется ввод-вывод, который был инициирован с этого ЦП, счетчик «простоя» увеличивается на единицу.
Предположим, что на процессоре работают две программы. Один - это «дд» чтение программы с диска. Другая - это программа, которая не выполняет ввода-вывода но тратит 100% своего времени на выполнение вычислительной работы. Теперь предположим что существует проблема с подсистемой ввода /вывода и что физические входы /выходы занимают второе место для завершения. Всякий раз, когда программа 'dd' спящий, ожидая завершения ввода-вывода, другая программа способный работать на этом CPU. Когда происходит прерывание часов, всегда быть программой, работающей в любом режиме пользователя или в системном режиме. Следовательно, значения% idle и% iowait будут равны 0. Хотя iowait 0, это не означает, что нет проблемы ввода-вывода, потому что очевидно, является одним, если физические входы /выходы занимают секунду полная.
Полный текст стоит прочитать. Вот зеркало этой страницы , если оно не работает.
Для Solaris я использую DTrace, чтобы посмотреть, что делают процессы, если мне нужно увидеть, какие операции ввода-вывода выполняются. Для Linux существует аналогичная программа под названием systemtap , которая обеспечивает аналогичный уровень воздействия на ядро и вызовы процессов.
Один пример, который я использовал при обучении DTrace, заключался в сравнении команды cp с командой dd . Вы можете видеть, что dd делает намного больше чтения для записи, а cp - нет, в основном из-за размера буфера dd по умолчанию используется (если я правильно помню).
Какие операции ввода-вывода будут зависеть от ваших приложений и настроек.
Важно, так как в некоторых случаях ЦП не может получить данные или инструкции, которые необходимо продолжить. В некоторых случаях это может продолжаться, но это будет зависеть от того, какие приложения работают, что он может сделать. Если у вас есть однопоточное приложение, которое делает много доступа к диску, вам нужно будет подождать.
Чтобы минимизировать время ввода-вывода, покупать все больше и быстрее памяти, получать более быстрые диски, дефрагментировать имеющиеся у вас диски.
Если это внутреннее приложение, которое является узким местом, посмотрите, можно ли его оптимизировать для чтения в больших блоках или для ввода IO асинхронно.
Использование ps aux может печатать процесс STAT
если stat - D или Ds, процесс находится в режиме бесперебойного сна (обычно IO)
когда процесс переходит в Бесперебойный сон, добавляется nr_iowait runqueue, и если nr_iowait> 0, время простоя cpu подсчитывается до iowait
vmstat также показывает, сколько блоков процесса r: количество процессов, ожидающих времени выполнения.
b: Количество процессов в режиме бесперебойного сна.
В разных 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-система при расчёте iowait ориентируется на отдельные процессоры, как часто бывает с категориями user, system и idle. Дело в том, что обычно ожидание результатов ввода-вывода не связано неким естественным образом с каким-то конкретным процессором. Похоже, что в illumos, если учесть то немногое, что об этом сказано в справке по mpstat, показатель iowait не рассматривается как нечто, относящееся к отдельным процессорам. А справка по sar(1) указывает на то, что в этой системе использован более общий подход к пониманию iowait.)
Пользуетесь ли вы показателем iowait при анализе производительности своих Unix-систем?
Столько, сколько я прочитал о Айовите, это все еще загадка для меня.
Я знаю, что это время, потраченное процессором на ожидание завершения операций ввода-вывода, но какой именно тип операций ввода-вывода? В чем я тоже не уверен, почему это так важно? Разве процессор не может просто сделать что-то еще, когда операция ввода-вывода завершится, и затем вернуться к обработке данных?
Кроме того, каковы правильные инструменты для диагностики того, какие процессы действительно ожидают ввода-вывода.
И как можно минимизировать время ожидания ввода-вывода?
Я знаю, что это время, потраченное процессором на ожидание завершения операций ввода-вывода, но какой именно тип операций ввода-вывода? В чем я тоже не уверен, почему это так важно? Разве процессор не может просто сделать что-то еще, когда операция ввода-вывода завершится, и затем вернуться к обработке данных?
Да, операционная система будет планировать запуск других процессов, пока один из них заблокирован на IO. Однако внутри этого процесса, если он не использует асинхронный ввод-вывод, он не будет выполняться до завершения какой-либо операции ввода-вывода.
Кроме того, каковы правильные инструменты для диагностики того, какие процессы действительно ожидают ввода-вывода.
Некоторые инструменты, которые вы можете найти полезными
- iostat , чтобы следить за временем обслуживания ваших дисков
- iotop (если ваше ядро поддерживает это), чтобы отслеживать разбивку запросов ввода-вывода на процесс
- strace , чтобы посмотреть на фактические операции, выпущенные процессом
И как можно минимизировать время ожидания ввода-вывода?
- убедитесь, что у вас есть свободная физическая память, чтобы ОС могла кешировать дисковые блоки в памяти
- держите дисковое пространство файловой системы ниже 80%, чтобы избежать чрезмерной фрагментации
- настроить вашу файловую систему
- использовать контроллер массива с батарейным питанием
- выбирайте хороший размер буфера при выполнении операций ввода-вывода
IOWait (обычно помеченный %wa сверху) является подкатегорией бездействия ( %idle обычно выражается как все бездействия, кроме определенных подкатегорий), то есть процессор ничего не делает. Поэтому, пока есть другой процесс, который процессор может обрабатывать, он будет это делать. Кроме того, время простоя, пользователь, система, iowait и т. Д. Являются измерением по отношению к процессору. Другими словами, вы можете думать о iowait как о бездействии, вызванном ожиданием io.
Точно, iowait - это время, потраченное на получение и обработку аппаратных прерываний в процентах от тактов процессора. Программные прерывания обычно помечаются отдельно как %si .
Важность и потенциальное заблуждение
IOWait важен, потому что он часто является ключевым показателем, чтобы узнать, нет ли у вас узких мест в IO. Но отсутствие iowait не обязательно означает, что ваше приложение не является узким местом при IO. Рассмотрим два приложения, работающие в системе. Если программа 1 сильно затруднена, а программа 2 является интенсивным пользователем %user + %system ЦП, загрузка ЦП все равно может составлять
100% и, соответственно, iowait будет показывать 0. Но это только потому, что программа 2 интенсивна и, по-видимому, ничего не говорит о программа 1, потому что все это с точки зрения процессора.
Смотрите посты Дейва Чейни и Ксеркс
Но и простое top покажет в %wa .
Кроме того, поскольку мы сейчас почти вступаем в 2013 год, в дополнение к тому, что говорили другие, доступны недорогие устройства хранения ввода-вывода, а именно SSD. Твердотельные накопители потрясающие .
iowait время, в течение которого процессор / процессоры ожидают (то есть находится в состоянии простоя и ничего не делает ), в течение которого фактически были невыполненные запросы дискового ввода-вывода.
Обычно это означает, что блочные устройства (то есть физические диски, а не память) слишком медленные или просто насыщены.
Следовательно, вы должны заметить, что если вы видите среднюю нагрузку в вашей системе и при проверке заметили, что большая часть этого на самом деле происходит из-за ожидания ввода-вывода, это не обязательно означает, что ваша система находится в неисправности - и это происходит, когда ваша машине просто нечего делать, кроме процессов, связанных с вводом / выводом (то есть процессов, которые делают больше операций ввода / вывода, чем что-либо еще (системные вызовы, не связанные с вводом / выводом)). Это также должно быть видно из того факта, что все, что вы делаете в системе, все еще очень отзывчиво.
инструменты
- sar (из sysstat пакета, доступного на большинстве машин * nix)
- iostat (интерфейс к sar )
Я нашел объяснение и примеры по этой ссылке очень полезными: что именно означает «Айоваит»? , Кстати, для полноты, ввод-вывод здесь относится к дисковому вводу-выводу, но может также включать в себя ввод-вывод на подключенном к сети диске (например, nfs), как объяснено в этом другом посте .
Я процитирую несколько важных разделов (в случае, если ссылка не работает), некоторые из них будут повторением того, что уже сказали другие, но мне, по крайней мере, это было более понятно:
Подводя итог, можно сказать, что в одном предложении «iowait» - это процент времени, в течение которого центральный процессор не используется, и выполняется хотя бы один ввод / вывод.
Каждый процессор может находиться в одном из четырех состояний: пользователь, sys, idle, iowait.
Мне было интересно, что происходит, когда в системе есть другие процессы, готовые к запуску, пока один процесс ожидает ввода-вывода. Ниже это объясняется:
Если процессор простаивает, ядро затем определяет, выполняется ли в настоящее время хотя бы один ввод-вывод на локальном диске или на удаленно смонтированном диске (NFS), который был инициирован с этого процессора. Если есть, то счетчик 'iowait' увеличивается на единицу. Если нет ввода-вывода, который был запущен из этого ЦП, счетчик «ожидания» увеличивается на единицу.
Допустим, на процессоре работают две программы. Одним из них является чтение программы «dd» с диска. Другая - это программа, которая не выполняет ввод-вывод, но тратит 100% своего времени на вычислительную работу. Теперь предположим, что есть проблема с подсистемой ввода-вывода и что физические операции ввода-вывода занимают секунду, чтобы завершиться. Всякий раз, когда программа dd спит в ожидании завершения ввода-вывода, другая программа может работать на этом процессоре. Когда происходит прерывание часов, всегда будет программа, работающая либо в пользовательском, либо в системном режиме. Таким образом, значения% idle и% iowait будут равны 0. Даже если iowait равен 0, это не означает, что нет проблемы ввода-вывода, потому что, очевидно, существует одна, если физические операции ввода-вывода занимают секунду для завершения.
Полный текст стоит прочитать. Вот зеркало этой страницы , на случай, если оно исчезнет.
Нагрузка на диски в 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. Также можно примерно оценить на одной машине производительность дисков и понимать, какой уровень "в среднем по больнице" вы можете ожидать. Это, конечно же, не правильно, но оценить все же поможет. Глубже анализировать результаты, а, главное, методики тестов мне пока трудно.
В общем виде запуск выглядит так:
Файл your.cfg (название произвольное) может быть примерно таким (пример рабочего конфига для теста на чтение):
Буферизацию не используем (buffered=0), чтение не последовательное (rw=randread).
Во время выполнения этого теста (а выполняться тест может доооолго, надоест - Ctrl+C, результаты все равно будут) можно запустить iostat и посмотреть, что происходит:
Как следует из названия, система вызванаобработатьПодождите. Более глубокий момент заключается в том, что в это время система выполняет io, в результате чего ни один процесс не работает, процессор выполняет незанятый процесс на холостом ходу, поэтому генерация iowait должна удовлетворять двум условиям: одно - процесс, ожидающий io, а другое - io Нет процесса для запуска.
Как рассчитывается Iowait?
Позвольте мне рассказать о том, как пользователи видят Айовит
Обычно мы видим iowat с помощью vmstat, wa на картинке (отмечена красным)
Вот этотданныеVmstat получается путем вычисления данных в файле / proc / stat, так что вы видите, что он может приблизительно отражать внешний вид данных уровня iowait системы. Что означают данные в / proc / stat? Давайте сами попробуем Google, поэтому я не буду вдаваться в подробности.
Откуда поступили данные в файле / proc / stat?
В ядре есть файл proc_misc.c, который будет выводить эти данные. Соответствующей функцией этого файла является show_stat.
Эта часть кода выведет данные, которые вы видите в / proc / stat. Из этого кода мы знаем, что iowait происходит из iowait = cputime64_add (iowait, kstat_cpu (i) .cpustat.iowait);
Так кто же модифицировал cpustat.iowait? Мы нашли эту функцию account_system_time
Мы можем видеть, что когда процессор генерирует iowait, то на процессоре должен быть процесс, который выполняет io и ожидает завершения ввода-вывода (rq-> nr_iowait> 0), и на этом процессоре нет процесса для запуска (p == rq-> idle), процессор находится в режиме ожидания.
Кто производит Айоваит?
Так кто же изменил rq-> nr_iowait?
Ключ наконец здесь, да.
Итак, основная причина iowait была найдена нами: это функции io_schedule, io_schedule_timeout. Как следует из названия, эти две функции используются для переключения процессов, а причина переключения - io. Только io_schedule_timeout также дает спатьвремя, Который является тайм-аут.
Системная карта, чтобы сказать, кто именно эти две функции вызываются, когда? Здесь мы возьмем движок в качестве примера, трассировку процесса searcher_server
Сценарий Stap Block.stp: (была перехвачена только часть программы)
Основная идея программы в 1С,статистикаКакой процесс вызвал эти две функции соответственно, сколько раз. И распечатайте стопку во время вызова, чтобы вы могли более четко увидеть, какой системный вызов выполнялся в этом месте.
В наиболее нормальном состоянии запустите машину:
В настоящее время у нового поисковика QPS 1500+, занятость процессора составляет 88%, iowait - почти 0, а память - м.mapПри использовании MAP_LOCKED всезамокВ памяти
Пройдя некоторое время, я обнаружил, что расписание io не вызывалось, что также соответствовало нашим ожиданиям. Мы запускаем дд в то время как Stap, чтобы захватить
sudo stap block.stp pid 5739 -DMAXSKIPPED=1000000 > directdd
Запустите два процесса dd, запишите данные 10G, не используйте кеш страниц, прямую запись
dd if=/dev/zero of=a count=20000000 oflag=direct
dd if=/dev/zero of=b count=20000000 oflag=direct
Написать в общей сложности 20 г
Cpu busy & iowait
Можно видеть, что iowait, сгенерированный прямым dd, чрезвычайно мал, а самый высокий - всего около 1.4, но он также оказывает небольшое влияние на поисковик.По результатам vmstat после выполнения dd переключение контекста процесса возросло с 2W + до 8W + и было заблокировано. искательНитьДля однозначных цифр.
Стек заблокированных потоков:
Согласно отслеживанию степа, увеличение количества переключений вызвано прямой дд: потому что это прямая запись, поэтому каждый раз писать по расписанию
Увеличение задержки Searcher связано с относительно умеренным расписанием и переключением процессов поискового устройства, но основной причиной в это время должно быть переключение процессов, которое также вызывает частую миграцию процессов, сброс TLB и загрязнение кэша.
Сделайте новый эксперимент и уберите прямой флаг dd, чтобы сделать кеш страниц эффективным
Операционная среда и работа поисковикадавлениеТо же, что и выше
Cpu busy & iowait：
Видно, что dd с кэшем страниц оказывает большее влияние на поисковик, давайте сначала посмотрим на данные, захваченные vmstat
В среднем, есть много заблокированных потоков данных, и даже количество потоков, которые могут быть запущены в определенное время, равно 0
Стек, когда поисковик заблокирован:
запрос записи блочного слоя
В настоящее время коэффициент загрязнения больше 40%, и необходимо выполнить blk_congestion_wait, что можно рассматривать как самое суровое наказание. ,
Некоторые страницы, используемые поисковиком, сильно удаляются, и требуется чтение страницы синхронизации.
При выполнении dd с использованием page cahce легко достичь коэффициента загрязнения фона 10% и коэффициента загрязнения 40%. Когда он достигает 40%, буферизованная запись становится синхронизированной записью. При трассировке обнаружилось, что каждый blk_congestion_wait занимает около 100 мс, что означает, что поток блокируется на 100 мс, что очень фатально.
Чтобы уменьшить влияние io, мы запретили логи
Сделать еще один эксперимент
Cpu busy & iowait
После выключения журнала все еще остается айовайт. Кто это вызвал?
Стек, когда поисковик заблокирован:
Наша память повреждена, и страница синхронизации еще есть. Почему?
Я преследовал его с помощью blktrace и debugfs и обнаружил, что это проблема с данными алгоритма
Оказалось, что данные этого файла были сброшены dd, что заставило его быть прочитанным обратно в память.
Затем написал программу для блокировки этих данных в памяти
Заблокируйте данные и снова запустите dd с кешем страниц
Cpu busy & iowait：
Видно, что уровень Айоваит сильно упал, так что в этот момент, кто все еще делает Айовит?
Стек, когда поисковик заблокирован:
Оказывается, что памяти очень мало, что приводит к try_to_free_pages (обычно редко) при обращении к памяти. Этот шаг показывает, что системная память уже жалкая. Но нет никакого способа. Кто попросил поисковик перейти на malloc? Эти mallocs состоят из двух частей: 1. Запрашиваемая mempool память фактически полностью стирается 2. Память, используемая частью STL в алгоритме, так.
Выключите журнал и заблокируйте данные в памяти, что снижает уровень iowait, но необходимо проделать дополнительную работу, чтобы не влиять на поисковик, например, не обращаясь к памяти.
Как устранить iowait поисковика (или системы приложений)?
Не пишите журналы и не оставляйте запись журнала в выделенном потоке, чтобы выполнить это, поисковик не выполняет буферизованную запись, не выполняет чтение с диска, особенно операции синхронизации страницы.
2. Полная память без обращения к памяти
Используемые данные считываются один раз, заполнены памятью и заблокированы, идеальный mempool, по крайней мере, в 99% случаев не распространяется на память.
3. Минимизировать влияние других приложений
Фактически, это может минимизировать негативное влияние dd, такое как использование cgroup: когда вы обрабатываете несколько больших файлов, вовремя очищайте кэш страниц каждого большого файла во время процесса передачи и сохраняете коэффициент загрязнения системы ниже 10%. В частности, он не может достигать 40%.
Читайте также: