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

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

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

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

Edit

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

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

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

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

iostat -txk 5

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

sudo sysctl vm.block_dump=1

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

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

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

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

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

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

hdparm -f

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

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

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

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

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

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