При запуске DTT iotop на сервере Solaris 10 с большим объемом записи, который запускает несколько зон с установленными демонами MySQL, я получаю следующий результат:
UID PID PPID CMD DEVICE MAJ MIN D BYTES
70 26636 1 mysqld sd1 10 64 R 360448
70 25940 1 mysqld sd1 10 64 R 530432
0 5 0 zpool-rpool sd1 10 64 W 17250816
Меня беспокоит то, что zpool-rpool занимает большую часть io. Что я могу сделать, чтобы увидеть, какой из MySQL или других процессов действительно выполняет операции ввода-вывода - более подробная разбивка? Если zpool-rpool обозначает "пишет в ZFS", то iotop мне тут уж не помогает ... :)
Спасибо!
Возможно, вы найдете недавнюю работу Брендана Грегга серия блогов о задержке файловой системы полезно. Он показывает пару сценариев для исследования использования файловой системы с помощью поставщика системных вызовов (который должен быть более надежным для определения ответственных процессов, чем поставщик io, используемый iotop).
Например, syscall-read-zfs.d сценарий, показанный в части 4, можно легко изменить для проверки записи и агрегирования по pid, а не по имени exec.
Вывод этого сценария также может быть более полезным, чем iotop, поскольку он показывает количество операций ввода-вывода и распределение задержки ввода-вывода на процесс. Для базы данных задержка чтения и синхронной записи является прямым показателем снижения производительности - его гораздо легче интерпретировать, чем количество байтов в секунду.
Если есть время, тоже очень рекомендую посмотреть его презентация на BayLISA для практической демонстрации того, как он исследует проблемы производительности запросов MySQL.
Если вы хотите измерить, какие приложения читают / записывают больше всего, вы хотите измерить на уровне системных вызовов. На уровне устройства свою работу выполняют только потоки ядра.