У мене процесор I / O чекає стабільно близько 50%, але коли я запускаю, iostat 1він показує мало-ніякої активності диска.

Які причини чекають без іопсів?

ПРИМІТКА: Тут немає файлових систем NFS або FUSE, але вона використовує віртуалізацію Xen.

NFS може це зробити, і мене не здивувало б, якщо інші мережеві файлові системи (і навіть пристрої на базі FUSE) мали подібні ефекти.

Чи є ймовірність, що інші VM на сервері обміняють диск?

Я знаю, що з віртуалізацією ви можете отримати дивні результати, якщо вузол хоста перевантажений.

Якщо це середовище Amazon EC2 Xen, використовуючи сховище, засноване на екземплярі, попросіть Amazon перевірити стан здоров'я хоста, що містить це зображення.

Якщо це середовище Xen, до якого ви можете отримати доступ до гіпервізора, то перевірте IOwait ззовні, щоб зображення диска (файл, мережа, шматочок LVM та інше) використовувалося для пристроїв xvda та xvdb. Ви також хочете перевірити систему вводу-виводу в цілому на гіпервізор, оскільки інші дискові пристрої можуть монополізувати ресурси системи.

iostat -txk 5

зазвичай є хорошим стартовим інструментом діагностики. Він потребує 5-секундних підсумків вводу / виводу для ВСІХ доступних йому пристроїв, і тому корисний як для вмивання, так і для зменшення зображення VM.

Перевірте наявні дескриптори / вставки файлів. Коли ви досягнете межі, вони поміняються місцями і імітують іоїт

Редагувати

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

Трохи пізно зараз, але встановіть munin, і це дійсно допоможе в майбутньому налагодження.

sudo sysctl vm.block_dump=1

Потім перевірте dmesg, щоб побачити, що виконує читання / запис блоку чи забруднення узорів.

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

ПОПЕРЕДЖЕННЯ: HDPARM ОПАСНИЙ, ВЖЕ ПРОЧИТАЙТЕ ПРО КОМАНДУ, ЯКІ ВИ ІЗ ВИКОРИСТАННЯ!

Якщо жодна інша віртуальна машина не робить напругу на жорсткому диску, зробіть це

hdparm -f

на базових фізичних дисках. Можливо, кеш диска не працює точно. Це змиває дані, що зберігаються в кеші, і ви можете постійно контролювати введення / вивід, чи не буде він знову підніматися після спалаху. Якщо так, це буде проблема кешу.

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

Можуть бути пристрої із зворотним зв'язком, які самі встановлюються через мережу.

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

SCP іноді також здається, що призводить до IO Wait, але набагато меншою мірою.

Це може бути що завгодно. Це просто означає, що щось чекає закінчення роботи вводу / виводу. Ви можете розібратися, який процес відбувається через ps, а потім приєднати до нього gdb і перевірити зворотній зв'язок, щоб визначити, який дзвінок зависає (зазвичай це деякі матеріали, пов’язані з мережею, або раптово відключений диск). Щоб отримати інформацію про fd, перевірте / проц.

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

Використання процесора було майже 0%, але 1 або більше процесорів у 4-ядерній системі витрачали 100% свого часу в IOwait протягом тривалого періоду часу (знайдено через topбагатолінійний дисплей процесора) з дуже низьким IOps та пропускною здатністю (знайдено через iostat), але бурхлива висока активність переривання. Використання інтерактивного командного рядка було болісним під час будь-якого доступу до диска (тобто автоматичного збереження від чиєїсь emacsсесії), але в іншому випадку допустимо, коли пройшли періоди IOwait (і, імовірно, операції вдалися після багатьох спроб).