☰

Анализ трафика дискового ввода-вывода

tag-icon • tag-icon ubuntu software-raid performance io
Анализ трафика дискового ввода-вывода

Я использую веб-сервер (Ubuntu 11.04), который демонстрирует неожиданно высокий трафик записи. Когда сервер вообще не должен писать, объем трафика записи сопоставим с трафиком чтения.

Обеспокоенный ненужной операцией записи, я попытался проанализировать, что не так в системе. Я могу исключить проблемы с тяжелым ведением журнала Apache или временем доступа (используянет времениконфигурация монтирования).

Чтобы отследить проблему, я хотел посмотреть, какие файлы были записаны. Поэтому я включил IO loggin через block_dump (полезная запись в блоге на эту тему:sprocket.io). Каждая активность файловой системы будет регистрироваться в syslog. Вот краткий отрывок из моей системы:

21 авг. 18:22:55 xxxxx ядро: [3984721.590864] apache2(2761): ЧТЕНИЕ блока 1098502400 на md2 (8 секторов)
21 авг. 18:22:55 xxxxx ядро: [3984721.594005] kjournald(316): ЗАПИСЬ блока 2224394648 на md2 (8 секторов)
21 авг. 18:22:55 xxxxx ядро: [3984721.594029] md2_raid1(260): ЗАПИСЬ блока 2925532672 на sdb3 (8 секторов)
21 авг. 18:22:55 xxxxx ядро: [3984721.594044] md2_raid1(260): ЗАПИСЬ блока 2925532672 на sda3 (8 секторов)
21 авг 18:22:55 xxxxx ядро: [3984721.644244] apache2(2761): ЧТЕНИЕ блока 2242118744 на md2 (8 секторов)

Хорошо, теперь я знаю, какие блоки были записаны. Но есть ли способ фактически идентифицировать имена файлов, которые были записаны, на основе этих идентификаторов блоков?

Спасибо за вашу помощь!

Кстати: я использую программный Raid, возможно, проблема в этом.

решение1

Предположим, что ext2/ext3/ext4, начните с

[406420.877412] vi(12496): READ block 4522288 on dm-1 (8 sectors)

Определите размер блока файловой системы:

# /sbin/dumpe2fs /dev/dm-1 | grep 'Block size'
dumpe2fs 1.42.3 (14-May-2012)
Block size:               4096

Предположим, что у вас есть диск с секторами по 512 байт, разделите блок на 4096/512, т. е. на 8, чтобы получить 565286.

Используется debugfsкомбинация icheckи ncheck:

debugfs:  icheck 565286
Block   Inode number
565286  142506

debugfs:  ncheck 142506
Inode   Pathname
142506  /etc/security/time.conf

Редактировать: сделайте это на устройствах md*, а не на устройствах sd*. Ввод-вывод устройства sd* является результатом программного рейда.

решение2

Файловая система находится на более высоком уровне абстракции, чем блочные устройства и программные RAID. При этом программный RAID не является частью проблемы с вероятностью 99,9%, это просто блочное устройство. Поэтому вам следует использовать другой набор инструментов для анализа активности ввода-вывода. Я бы рекомендовал начать с iotopопределения самого активного писателя среди запущенных процессов. Затем вы сможете использовать lsofи straceопределить, в какие файлы записывается информация.

решение3

Linux имеет систему ядра, которая называетсяinotifyдля просмотра любых изменений в файле. В пользовательском пространстве можно использоватьinotify-инструменты( apt-get install inotify-tools) для наблюдения за каталогом. Однако для каждого файла необходимо установить индивидуальный контроль. Вы можете рекурсивно применить их к каталогу (даже к корневому), но чем меньше вы наблюдаете, тем меньше накладных расходов.

Другие варианты сужения круга поиска включают:

  • atopчто позволит вам увидеть, какие процессы выполняют запись
  • auditctlкоторый имеет очень запутанный синтаксис, но позволяет устанавливать наблюдение за любым системным вызовом

Связанный контент