У меня процессорное ожидание ввода / вывода около 50%, но когда я запускаю, iostat 1он показывает, что активность диска практически отсутствует.

Что вызывает ожидание без iops?

ПРИМЕЧАНИЕ. Здесь нет файловых систем NFS или FUSE, но используется виртуализация Xen.

NFS может сделать это, и меня не удивит, если другие сетевые файловые системы (и даже устройства на основе FUSE) будут иметь подобные эффекты.

Есть ли вероятность, что другие виртуальные машины на сервере перебивают диск?

Я знаю с виртуализацией, что вы можете получить некоторые странные результаты, если узел хоста перегружен.

Если это среда Amazon EC2 Xen, использующая хранилище на основе экземпляров, попросите Amazon проверить работоспособность хоста, содержащего этот образ.

Если это среда Xen, к которой вы можете получить доступ к гипервизору, проверьте IOwait извне на наличие образа диска (файл, сеть, LVM-фрагмент и т. Д.), Используемого для устройств xvda и xvdb. Вы также захотите проверить систему ввода-вывода, в общем, для гипервизора, поскольку другие дисковые устройства могут монополизировать ресурсы системы.

iostat -txk 5

обычно хороший стартовый диагностический инструмент. Он берет 5-секундные сводки ввода / вывода для ВСЕХ доступных ему устройств и, таким образом, полезен как с образом ВМ, так и без него.

Проверьте ваши доступные файловые дескрипторы / иноды. Когда вы достигнете предела, они меняются местами и имитируют Айовит

редактировать

Я видел, что вы используете xen, посмотрите текущие прерывания, вы можете обнаружить, что blkif выше, чем обычно.

Немного поздно, но установите munin, и это действительно поможет в дальнейшей отладке.

sudo sysctl vm.block_dump=1

Затем проверьте dmesg, чтобы увидеть, что выполняет чтение / запись блока или загрязняет inode.

Также проверьте ограничение nofile в limit.conf, процесс может запрашивать больше файлов, чем разрешено открывать.

ВНИМАНИЕ: HDPARM ОПАСЕН, ВСЕГДА ПРОЧИТАЙТЕ О КОМАНДЕ, которую ВЫ ИСПОЛЬЗУЕТЕ!

Если никакие другие виртуальные машины не нагружают жесткий диск (и), сделайте

hdparm -f

на базовом физическом диске (ах). Возможно, кэш диска не работает точно. Это очистит данные, хранящиеся в кэше, и вы сможете постоянно контролировать ввод-вывод, собирается ли он снова расти после сброса. Если да, то это будет проблема с кешем.

Со средней нагрузкой я видел увеличение количества заблокированных сетевых операций (то есть длительных вызовов на внешний сервер БД). Я не знаю точно, но я предполагаю, что сетевой ввод-вывод может привести к увеличению загрузки ЦП? Кто-нибудь может подтвердить?

Это могут быть петлевые устройства, которые сами монтируются по сети.

На моих машинах NFS является крупнейшим IO-WAIT "производителем". У меня в ноутбуке SSD, который работает очень быстро, поэтому проблема «реального ввода-вывода» не в этом. Тем не менее, у меня иногда много ожидания ввода-вывода из-за моих подключенных NFS-ресурсов.

Иногда кажется, что SCP также приводит к IO Wait, но в гораздо меньшей степени.

Это может быть что угодно. Это просто означает, что что-то ожидает завершения операции ввода-вывода. Вы можете выяснить, что это за процесс, через ps, затем подключить к нему gdb и проверить обратную трассировку, чтобы определить, какой вызов зависает (обычно это какой-то материал, связанный с сетью, или внезапно отключенный диск). Для получения информации о fd, проверьте / proc.

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

Загрузка ЦП составляла около 0%, но 1 или более ЦП в четырехъядерной системе тратили 100% своего времени в IOwait в течение продолжительных периодов времени (обнаруживается с помощью topмногострочного дисплея ЦП) при очень низких IOps и пропускной способности (найдено через iostat), но прерывистая высокая активность прерывания. Интерактивное использование командной строки было болезненным при любом доступе к диску (т. emacsЕ. Автоматическом сохранении из чьего-либо сеанса), но в остальном терпимо по прошествии периодов IOwait (и, вероятно, операции выполнялись успешно после многих попыток).