Перейти к содержимому 
Я шаг за шагом показываю, как анализ ожидания ввода-вывода с помощью iostat и vmstat позволяет увидеть узкие места и какие показатели Linux-сервера важны для быстрого времени отклика. При этом я устанавливаю четкие пороговые значения, интерпретирую типичные закономерности и предлагаю конкретные меры по оптимизации ВВОД/ВЫВОД и CPU в.
Центральные пункты
- iostat и vmstat обеспечивают дополнительное представление о загрузке процессора и хранилища.
- wa через 15-20% и %utile через 80% свидетельствует об узком месте ввода-вывода.
- ожидайте и avgqu-sz объясните, что такое латентность и очереди.
- mpstat обнаруживает неравномерное распределение нагрузки по ядрам процессора.
- Тюнинг варьируется от MySQL к параметрам и хранилищу ядра.
Что означает I/O Wait на серверах Linux?
При ожидании ввода-вывода процессор простаивает, поскольку ожидает более медленных устройств памяти или сети, что можно рассматривать как wa-значение в таких инструментах, как top или vmstat. Я оцениваю эту долю как время, в течение которого потоки блокируются, а запросы выполняются позже, что непосредственно ощущается пользователями как медлительность. Значения выше 10-20% часто указывают на полностью загруженную систему. Хранение-подсистема, например, когда жесткие диски, RAID-массивы или NFS-монтирования используются на полную мощность. В хостинговых системах с базами данных неиндексированные запросы и пики записи приводят к ненужному времени ожидания на Диск. Если вы хотите подтянуть знания, то можете ознакомиться с основами на сайте Понимание I/O‑Wait, перед тем, как отправиться на тренировку.
Быстрый старт: читаем vmstat правильно
С помощью vmstat я могу проверить наиболее важные Linux-и распознать первые закономерности без особых усилий. Вызов vmstat 1 10 предоставляет десять снимков, на которых я обращаю особое внимание на столбцы wa (ожидание ввода-вывода), bi/bo (блочный ввод-вывод) и si/so (своп). Для меня высокие значения bo при одновременном увеличении wa указывают на большое количество блокирующих обращений к записи, что часто свидетельствует о нехватке буфера или медленном носителе. Если si/so остается на нуле, а wa значительно увеличивается, возникает подозрение, что это чистый Хранение-лимит. На многоядерных хостах я комбинирую vmstat с mpstat -P ALL 1, поскольку ожидание ввода-вывода часто затрагивает только отдельные ядра и поэтому в среднем кажется более безобидным, чем есть на самом деле.
Тонкий образ процессора: us/sy/st, очередь выполнения и переключение контекста
С помощью vmstat и mpstat я читаю не только wa: Высокий мыРабота с "тяжелыми" приложениями показана в следующих разделах, sy указывает на работу ядра/драйвера, например, с интенсивным ВВОД/ВЫВОД. В виртуализированных средах я обращаю внимание на ул. (Steal): Высокие значения st означают, что ВМ теряет процессорное время, что искусственно увеличивает задержки при идентичном шаблоне ввода-вывода. Я также сравниваю очередь выполнения (r в vmstat) с числом процессоров: Постоянно превышающее число процессоров значение r указывает на перегрузку процессора, а не на Хранение. Многие изменения контекста (cs) в сочетании с небольшими синхронными записями являются индикатором болтливых шаблонов ввода-вывода. Таким образом я избегаю ошибочной интерпретации нехватки процессора как проблемы ввода-вывода.
Глубокое понимание iostat: важные метрики
iostat -x 1 дает расширенную версию Диск-метрики, которые четко описывают задержку, использование и очереди. Я начинаю измерения в пики нагрузки и соотношу %util, await, svctm и avgqu-sz, чтобы выявить причину и следствие. Если %util поднимается до 90-100%, а await и avgqu-sz также растут, я вижу насыщенность Тарелка или ограниченный объем. Если ожидание показывает высокие значения при умеренном %util, я проверяю, нет ли помех от кэширования, ограничений контроллера или отдельных больших запросов. r/s и w/s вносят в картину частоту, а MB_read и MB_wrtn объясняют объем, что дает мне важные сравнительные значения для выделенных SSD и NVMe-установок.
NVMe, SATA и RAID: что означают %util, await и глубина очереди
Я делаю строгое различие между типами медиа: HDD показывать больше ожидайте-значения даже при умеренной подсказке, поскольку доминируют движения головы. SSD/NVMe хорошо масштабируется с параллелизмом, поэтому более высокое значение avgqu-sz может быть нормальным до тех пор, пока ожидайте остается в пределах нормы. На NVMe с несколькими очередями отправки/завершения я читаю %util более осторожно: отдельные устройства могут быть на пределе уже при 60-70%, если приложение не генерирует достаточный параллелизм или глубина очереди (nr_requests, глубина очереди) слишком мала. В RAID Я проверяю, не сталкивается ли рассеянный случайный ввод-вывод со слишком маленькими размерами полос; тогда ожидайте и %utile неравномерно на дисках-членах. Поэтому я смотрю iostat на каждое устройство-член, а не только на составной том, чтобы выявить горячие точки. Для уровней с журнальной структурой (например, копирование при записи) я ожидаю немного более высоких задержек при записи, но компенсирую это увеличенными окнами записи или пакетной обработкой на стороне приложения.
Диагностический процесс при длительном ожидании
Я запускаю каждый анализ параллельно с vmstat 1 и iostat -x 1, чтобы синхронно видеть состояния процессора и устройств и привязывать их ко времени. Затем я использую mpstat -P ALL 1, чтобы проверить, не работают ли отдельные ядра в необычно высоком режиме. wa что предотвращает неправильную интерпретацию средних значений. Если есть признаки причины, я использую pidstat -d или iotop, чтобы узнать, какой именно PID использует больше всего долей ввода-вывода. В хостинговых средах с базами данных я сначала различаю пики чтения и записи, поскольку стратегии обратной записи и шаблоны fsync вызывают совершенно разные симптомы и поэтому могут быть использованы для целенаправленной работы. Меры делают это возможным. Для более глубокого изучения вопросов хранения данных можно воспользоваться обзором, подобным тому, что представлен на сайте Узкое место ввода-вывода в хостинге, перед тем, как настраивать ядро или файловую систему.
Четкое разграничение между виртуализацией и контейнерами
В виртуальных машинах я рассматриваю wa вместе с ул. (Steal) и дополнительно измерять на гипервизоре, потому что только там находятся реальные устройства и Кии видны. Агрегации хранилищ (thin provisioning, dedupe, snapshots) перемещают пики задержки вниз по стеку - на ВМ это имеет следующий эффект ожидайте прыгает, а %util остается незаметным. В контейнерах я ограничиваю или развязываю ВВОД/ВЫВОД с правилами Cgroup (например, ограничениями IOPS/пропускной способности) для того, чтобы Шумные соседи чтобы укротить их. Я документирую пределы для каждого сервиса, чтобы измеренные значения были воспроизводимы, а сигналы тревоги сохраняли свой контекст. Важно: высокий wa на ВМ может быть вызвано резервным копированием, очисткой или перестройкой всего хоста - я сопоставляю время с заданиями хоста, прежде чем прикоснуться к приложению.
Пределы, пороговые значения и дальнейшие шаги
Я использую несколько четких пороговых значений, чтобы определить, есть ли реальное узкое место и какие действия нужно предпринять, чтобы заметно стабилизировать производительность. Я принимаю во внимание тип носителя, рабочую нагрузку и требования к задержкам, поскольку одни и те же показатели на HDD и NVMe имеют разные последствия. Я использую следующую таблицу в качестве краткого руководства, которое я использую в своих плейбуках. Я провожу измерения несколько раз в течение нескольких минут и под нагрузкой, чтобы исключить ложные срабатывания и выявить тенденции. Я использую это как основу для целенаправленных действий вместо рефлекторной замены оборудования или Параметры очень сильно.
| Метрики | Порог | интерпретация | Следующие шаги |
|---|---|---|---|
| wa (vmstat) | > 15-20% | Значительное время ожидания ввода/вывода | Проверьте iostat; найдите причину с помощью pidstat/iotop; проанализируйте кэширование и запись. |
| %utile (iostat) | > 80-90% | Используемое устройство | соотнесите await/avgqu-sz; проверьте глубину очереди, планировщик, RAID и SSD/NVMe |
| ожидайте (мс) | > 10-20 мс SSD, > 30-50 мс HDD | Увеличенная задержка | Различайте случайные и последовательные файлы; настраивайте параметры файловой системы, запись, журналирование |
| avgqu-sz | > 1-2 стойких | Очередь растет | Уменьшение/увеличение параллелизма; оптимизация схемы ввода-вывода приложения; проверка ограничений контроллера |
| си/со (vmstat) | > 0 под нагрузкой | Узкое место в системе хранения данных | Увеличение оперативной памяти; настройка запросов/кэша; проверка ограничений на свопизм/память |
Причины в стеке: БД, файловая система, виртуализация
В базах данных я часто вижу неиндексированные соединения, слишком маленькие буферы и чрезмерные вызовы fsync в качестве фактического Причины для высоких значений ожидания. Я проверяю планы запросов, активирую журналы для медленных операторов и объективно настраиваю такие размеры, как буферный пул InnoDB, размеры файлов журналов и открытых файлов. На уровне файловой системы я смотрю на параметры монтирования, режимы журналирования и выравнивание по полосе RAID, поскольку неправильные комбинации приводят к взрыву времени ожидания. В виртуализированных системах я не полагаюсь на измерения только в виртуальной машине, а смотрю на хост, поскольку именно там находятся реальные блочные устройства и Кии становятся видимыми. Это позволяет мне четко отделить эффекты дедупликации, тонкого выделения ресурсов или соседних ВМ от шаблонов приложений.
Подробно о файловой системе и параметрах монтирования
Я оцениваю файловые системы с учетом рабочей нагрузки: ext4 в упорядоченном режиме или режиме обратной записи минимизирует препятствия для интенсивности записи, в то время как XFS оценивается по достоинству благодаря дизайну журнала для параллельных рабочих нагрузок. Такие опции, как noatime или относительное время Сократите количество записей метаданных, lazytime перемещает обновления временных меток на запись в пачки. Для журналирования я проверяю интервалы фиксации (например, commit=) и проверяю, не усугубляют ли принудительные сбросы (барьеры) политики кэширования контроллера. На RAID я обращаю внимание на чистое выравнивание по полосе (Parted/FDISK с началом 1MiB), иначе ожидайте через Read-Modify-Write даже при якобы последовательных шаблонах. Для баз данных я часто использую стратегии O_DIRECT или прямого смывания журнала - но только после измерения, потому что кэш файловой системы может значительно снизить нагрузку на чтение, если рабочий набор в него помещается.
Тюнинг: от ядра до приложения
Я начинаю с простых побед, например, с индексирования запросов, пакетной записи и разумной конфигурации пула соединений, прежде чем приступать к системному уровню. Для записи я настраиваю vm.dirty_background_ratio, vm.dirty_ratio и vm.dirty_expire_centisecs контролируемым образом, чтобы система писала смежно и создавала меньше блокировок, не засоряя память. Для блочных устройств я проверяю планировщик ввода-вывода, глубину очереди и опережающее чтение, поскольку эти параметры напрямую влияют на задержку и пропускную способность. На RAID-контроллерах я настраиваю размер полосы и политику кэширования, а на SSD/NVMe для прошивки, TRIM и последовательных настроек overprovisioning. После каждого изменения я проверяю с помощью vmstat и iostat в течение нескольких минут, падает ли ожидание и остается ли стабильным %util, прежде чем перейти к следующему шагу.
Прерывания, NUMA и родственные связи
Я слежу за загрузкой IRQ и топологией NUMA, поскольку и то, и другое заметно влияет на задержки. NVMe-Я привязываю прерывания к процессорам NUMA-домена контроллера с помощью аффинити, чтобы пути передачи данных оставались короткими. Если IRQ-шторм работает на ядре, я вижу высокий уровень sy а остальные процессоры, похоже, простаивают; mpstat раскрывает это. Я разрешаю irqbalance только в том случае, если дистрибутив соответствует аппаратному обеспечению - в противном случае я устанавливаю определенные привязки. Я также проверяю, соответствует ли приложение и его ВВОД/ВЫВОД работают в одной и той же зоне NUMA (место хранения), поскольку межсокетные доступы вызывают время ожидания в ожидайте может быть замаскирован.
Автоматизация и визуализация измерений
Чтобы убедиться в том, что я распознаю тенденции, я автоматизирую измерения и интегрирую iostat/vmstat в инструменты мониторинга, которые могут отображать исторические данные. Данные сохранять. Я устанавливаю консервативные сигналы тревоги, например, wa > 15% в течение нескольких интервалов, в сочетании с пороговыми значениями await и %util, чтобы избежать ложных срабатываний. Для общих экранов метрик я использую панели, на которых сопоставляются показатели процессора, хранилища, сети и приложений, чтобы корреляции были видны сразу. Если вам нужно введение в метрики, вы можете найти их на сайте Показатели сервера компактный контекст для повседневной работы. Для меня важен повторяющийся процесс: измерение, формирование гипотезы, корректировка, повторное измерение и окончательная обработка результатов. Результаты документ.
Воспроизводимые нагрузочные испытания с помощью fio
Если у меня нет реальной нагрузки или я хочу проверить гипотезы, я использую короткоживущие fio-тесты. Я моделирую репрезентативные шаблоны (например, случайное чтение 4k, последовательная запись 64k, смешанные профили 70/30) и варьирую йодглубина, чтобы установить окно "сладкого пятна" между ожидайте и пропускной способности. Я строго отделяю тестовые пути от производственных данных и отмечаю граничные условия (файловая система, параметры монтирования, планировщик, глубина очереди), чтобы правильно классифицировать результаты. После настройки те же тесты используются в качестве регрессионной проверки; только когда ожидайте и %utile чтобы они выглядели лучше, я вношу изменения в поверхность.
Распознавание моделей ошибок: типичные модели
Если я наблюдаю высокий wa при одновременно высоком %utile и растущем avgqu-sz, все говорит в пользу насыщения на Устройство, т.е. реальные физические пределы. Высокие значения await при умеренных значениях %util, как правило, указывают на особенности контроллера или кэширования, такие как барьеры, пропуск записи или спорадическая очистка. Растущие значения si/so вместе с провалами в кэше явно указывают на нехватку оперативной памяти, что искусственно завышает скорость ввода-вывода и увеличивает время ожидания. Если диск остается незаметным, но приложение выполняет большие синхронные записи, я переключаю работу на асинхронную запись, конвейеризацию или Партия-механизмы. В системах NFS или сетевых хранилищах я также проверяю латентность, MTU, ретрансляции и кэширование на стороне сервера, поскольку сетевое время здесь напрямую маскируется под латентность ввода-вывода.
NFS/iSCSI и распределенное хранение данных
На сайте NFS и iSCSI, я различаю устройства и сетевые пути: iostat показывает только то, что видит блочный уровень - я также распознаю ретрансляции, задержки и проблемы с окнами через сетевые метрики. Высокий ожидайте с умеренным %utile на виртуальном блочном устройстве типична для случаев, когда сеть замирает или кэш на стороне сервера остывает. Для NFS я проверяю параметры монтирования (rsize/wsize, proto, sync/async) и серверную часть (потоки, политики экспорта, кэш), для iSCSI - параметры сессии и очереди. Я планирую окна обслуживания для серверных заданий (чистка, перестройка, ребалансировка) таким образом, чтобы они не переполняли общее хранилище в пиковые моменты и не приводили к недоступности сервера. wa на всех клиентах.
Практические примеры: три коротких сценария
Кластер блогов с советами по написанию статей
В прайм-тайм комментарии и аннулирование кэша увеличиваются, после чего await и avgqu-sz в iostat значительно возрастают, а %util остается на уровне 95%. Я аккуратно увеличиваю параметры записи, оптимизирую аннулирование кэша на уровне путей и увеличиваю буфер журнала InnoDB, чтобы было меньше мелких синхронных записей. После этого ожидание ощутимо падает, значения bo остаются высокими, а wa падает, что сразу же сокращает время отклика. В то же время я заменяю отдельные жесткие диски на SSD для журнала, что дополнительно снижает нагрузку на узкое место. Схема показывает, как Партия-Сочетайте письмо и ускоренное ведение дневника.
Магазин с пиками для чтения и поисковыми индексами
Акции создают большую нагрузку на чтение, r/s растет, ожидание остается умеренным, но приложение по-прежнему вяло реагирует на навигацию по фильтрам. Я обнаружил множество небуферизованных запросов без подходящих индексов, которые превышают рабочий набор кэша файловой системы. При целенаправленном индексировании и перезаписи запросов r/s падает, хиты чаще попадают в кэш, а iostat подтверждает более низкий MB_read при той же пропускной способности. В то же время я немного увеличиваю read-ahead для более эффективного обслуживания последовательных сканирований, что еще больше снижает задержки. Вот как я проверяю, что Читать-паттерны снова приводят к попаданию в кэш.
Хост виртуальной машины с „шумным соседом“
В отдельных ВМ top показывает высокий wa, но iostat в ВМ видит только виртуальные устройства с недостоверной загрузкой. Я также провожу измерения на гипервизоре, вижу переполненные реальные блочные устройства и определяю, что причиной является соседняя ВМ с агрессивным резервным копированием. Ограничение пропускной способности и изменение окон резервного копирования стабилизируют ожидание и %util на всем хосте. Затем я снова провожу измерения в ВМ и на хосте, чтобы подтвердить и предотвратить эффект с обеих сторон. Это подтверждает, что реальный Устройства-Метрики всегда показывают правду на хосте.
Контрольный список для следующего инцидента
Сначала я запускаю журналы и измерения, чтобы не потерять сигналы, и держу запущенными vmstat 1 и iostat -x 1 в течение нескольких минут. Затем я сопоставляю пики по времени с событиями приложений и системными таймерами, после чего отлавливаю отдельные процессы с помощью pidstat -d и формулирую гипотезы. На следующем этапе проверяются хиты памяти, свопа и кэша, чтобы нехватка оперативной памяти не была ошибочно распознана как Диск-проблема появляется. Только когда я выявил причину, я меняю только одну вещь, регистрирую настройку и оцениваю эффект на await, %util и wa. Таким образом, я сохраняю воспроизводимость анализа, извлекаю уроки из каждого инцидента и сокращаю время до Решение однозначно.
Частые неправильные толкования и камни преткновения
Меня не обманывают отдельные пики: Одиночные секунды с высокими wa являются нормальными, только устойчивые плато указывают на наличие структурного узкого места. %utile близкий к 100%, является критическим только в том случае, если ожидайте поднимается одновременно - в противном случае устройство просто занято. На сайте SSD/NVMe является более высоким avgqu-sz часто намеренно, чтобы задействовать внутренний параллелизм; я дросселирую только в тех случаях, когда цели по задержке не достигнуты. Я проверяю масштабирование частоты процессора: агрессивное энергосбережение может увеличить время отклика, и поэтому wa кажется, ухудшается. И я отделяю TTFB приложения от латентности хранилища - сеть, рукопожатия TLS и вышестоящие службы могут вызывать подобные симптомы без iostat „является “виновным".
Краткое резюме для администраторов
Анализ ожидания ввода-вывода с помощью iostat и vmstat работает быстро, если я читаю wa, await, %util и avgqu-sz вместе и соотношу их с контекстом рабочей нагрузки. Сначала я определяю, действительно ли происходит перенасыщение устройства, или же задержки обусловлены работой памяти и приложений, а затем выбираю подходящий рычаг. Небольшие, целенаправленные изменения в запросах, параметрах записи, планировщиках или глубине очереди часто дают наибольший эффект, прежде чем потребуется дорогостоящая замена оборудования. Измерения, гипотезы, изменения и повторные измерения остаются для меня неизменной последовательностью, чтобы решения оставались понятными и повторяемыми. Именно так я поддерживаю Linux-сервер работает быстрее и обеспечивает заметно лучшие показатели Время реагирования под нагрузкой.
