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

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

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

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

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

iostat -txk 5

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

sudo sysctl vm.block_dump=1

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

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

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

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

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

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

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

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

hdparm -f

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

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

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

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

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

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

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

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