Меня интересует утилита или процесс для мониторинга ввода-вывода диска на файл на CentOS.
В Win2008 Resmon Утилита позволяет использовать этот тип детализации, но ни одна из обнаруженных мною утилит Linux этого не делает (iostat, iotop, dstat, nmon).
Мой интерес к мониторингу узких мест ввода-вывода на серверах баз данных. С помощью MSSQL я обнаружил, что это информативная диагностика, позволяющая узнать, какие файлы / файловые пространства страдают больше всего.
SystemTap вероятно, ваш лучший вариант.
Вот как вывод iotime.stp пример выглядит так:
825946 3364 (NetworkManager) access /sys/class/net/eth0/carrier read: 8190 write: 0
825955 3364 (NetworkManager) iotime /sys/class/net/eth0/carrier time: 9
[...]
117061 2460 (pcscd) access /dev/bus/usb/003/001 read: 43 write: 0
117065 2460 (pcscd) iotime /dev/bus/usb/003/001 time: 7
[...]
3973737 2886 (sendmail) access /proc/loadavg read: 4096 write: 0
3973744 2886 (sendmail) iotime /proc/loadavg time: 11
Недостатком (помимо кривой обучения) является то, что вам нужно будет установить отладка ядра, что может быть невозможно в производственной системе. Однако можно прибегнуть к кросс-инструментарий где вы компилируете модуль в системе разработки и запускаете его .ko по производственной системе.
Или, если вы нетерпеливы, посмотрите на Глава 4. Полезные скрипты SystemTap из руководства для начинающих.
SystemTap* сценарий:
#!/usr/bin/env stap
#
# Monitor the I/O of a program.
#
# Usage:
# ./monitor-io.stp name-of-the-program
global program_name = @1
probe begin {
printf("%5s %1s %6s %7s %s\n",
"PID", "D", "BYTES", "us", "FILE")
}
probe vfs.read.return, vfs.write.return {
# skip other programs
if (execname() != program_name)
next
if (devname=="N/A")
next
time_delta = gettimeofday_us() - @entry(gettimeofday_us())
direction = name == "vfs.read" ? "R" : "W"
# If you want only the filename, use
// filename = kernel_string($file->f_path->dentry->d_name->name)
# If you want only the path from the mountpoint, use
// filename = devname . "," . reverse_path_walk($file->f_path->dentry)
# If you want the full path, use
filename = task_dentry_path(task_current(),
$file->f_path->dentry,
$file->f_path->mnt)
printf("%5d %1s %6d %7d %s\n",
pid(), direction, $return, time_delta, filename)
}
Результат выглядит так:
[root@sl6 ~]# ./monitor-io.stp cat
PID D BYTES us FILE
3117 R 224 2 /lib/ld-2.12.so
3117 R 512 3 /lib/libc-2.12.so
3117 R 17989 700 /usr/share/doc/grub-0.97/COPYING
3117 R 0 3 /usr/share/doc/grub-0.97/COPYING
Или, если вы решите отображать только путь от точки монтирования:
[root@f19 ~]# ./monitor-io.stp cat
PID D BYTES us FILE
26207 R 392 4 vda3,usr/lib64/ld-2.17.so
26207 R 832 3 vda3,usr/lib64/libc-2.17.so
26207 R 1758 4 vda3,etc/passwd
26207 R 0 1 vda3,etc/passwd
26208 R 392 3 vda3,usr/lib64/ld-2.17.so
26208 R 832 3 vda3,usr/lib64/libc-2.17.so
26208 R 35147 16 vdb7,ciupicri/doc/grub2-2.00/COPYING
26208 R 0 2 vdb7,ciupicri/doc/grub2-2.00/COPYING
[root@f19 ~]# mount | grep -E '(vda3|vdb7)'
/dev/vda3 on / type ext4 (rw,relatime,seclabel,data=ordered)
/dev/vdb7 on /mnt/mnt1/mnt11/data type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
Ограничения / ошибки:
devname
является "N/A"
devname
является "N/A"
Результаты для Мэтью Ифепрограммы:
для mmaptest частный:
PID D BYTES us FILE
3140 R 392 5 vda3,usr/lib64/ld-2.17.so
3140 R 832 5 vda3,usr/lib64/libc-2.17.so
3140 W 23 9 N/A,3
3140 W 23 4 N/A,3
3140 W 17 3 N/A,3
3140 W 17 118 N/A,3
3140 W 17 125 N/A,3
для mmaptest общий:
PID D BYTES us FILE
3168 R 392 3 vda3,usr/lib64/ld-2.17.so
3168 R 832 3 vda3,usr/lib64/libc-2.17.so
3168 W 23 7 N/A,3
3168 W 23 2 N/A,3
3168 W 17 2 N/A,3
3168 W 17 98 N/A,3
для диотест (прямой ввод / вывод):
PID D BYTES us FILE
3178 R 392 2 vda3,usr/lib64/ld-2.17.so
3178 R 832 3 vda3,usr/lib64/libc-2.17.so
3178 W 16 6 N/A,3
3178 W 1048576 509 vda3,var/tmp/test_dio.dat
3178 R 1048576 244 vda3,var/tmp/test_dio.dat
3178 W 16 25 N/A,3
*Инструкции по быстрой установке для RHEL 6 или аналогичного: yum install systemtap
и debuginfo-install kernel
Вы бы действительно хотели использовать blktrace
для этого. Видеть Визуализация ввода-вывода Linux с помощью Seekwatcher и blktrace.
Я посмотрю, смогу ли я в ближайшее время опубликовать один из моих примеров.
Редактировать:
Вы не упоминаете дистрибутив Linux, но, возможно, это хороший случай для скрипт dtrace в Linux или даже Системный кран, если вы используете систему, подобную RHEL.
используйте iotop, чтобы получить PID процессов, которые вносят высокий IO
запустите strace против сгенерированного вами PID, вы увидите, к каким файлам обращается конкретный процесс
strace -f -p $PID -e trace=open,read,write
Единственный известный мне инструмент, который может отслеживать активность ввода-вывода по файлам, - это inotifywatch
. Это часть inotify-tools
пакет. К сожалению, это дает вам только количество операций.
В конце концов я использовал Sysdig для этого
Я бы сказал, что вы задали неправильный вопрос. если вы ищете узкие места ввода-вывода, не менее важно посмотреть, что происходит на вашем диске. db известны тем, что выполняют случайный ввод-вывод, что может значительно снизить пропускную способность, особенно если у вас всего несколько шпинделей.
что может быть более интересным, так это посмотреть, есть ли у вас долгое время ожидания самих дисков. вы можете сделать это с помощью collectl с помощью команды "collectl -sD", которая покажет статистику производительности отдельных дисков. Are --home, чтобы превратить его в утилиту типа top. Если задействовано много дисков, запустите его с помощью команды colmux: colmux -command «-sD», и она позволит вам сортировать по столбцу по вашему выбору даже в нескольких системах.
Вы можете отслеживать ввод-вывод для каждого блочного устройства (через / proc / diskstats) и для каждого процесса (учет io через /proc/$PID/io
или статистика задач), но я не знаю, как сделать это для каждого файла.
Может быть inotify решит решить эту проблему.
API inotify предоставляет механизм для мониторинга событий файловой системы. Inotify можно использовать для мониторинга отдельных файлов или каталогов. Когда каталог отслеживается, inotify будет возвращать события для самого каталога и для файлов внутри каталога.
Хотя здесь много полезной информации, мне интересно, действительно ли это применимо?
Если вы говорите о файлах размером в 10 гигабайт, которые постоянно записываются, то, если они не являются файлами журнала или аналогичными, которые постоянно добавляются (в этом случае просто отслеживайте размеры файлов), скорее всего, файлы являются mmap'd . Если это так, то лучшим ответом может быть то, что вам следует перестать искать большинство решений. Первое, что вы должны затем спросить у любого другого предлагаемого решения, это «работает ли оно с mmap», потому что в большинстве случаев они этого не делают. Однако вы можете превратить проблему в мониторинг блочного устройства, а не в мониторинг файла.
Когда программа запрашивает страницу из файла mmap, она просто ссылается на место в виртуальной памяти. Эта страница может быть или не быть в памяти. Если это не так, то возникает ошибка страницы, которая запускает загрузку страницы с диска, но это происходит в системе виртуальной памяти, которую нелегко привязать к конкретному процессу приложения или конкретному файлу. Точно так же, когда ваше приложение обновляет страницу mmap'd, в зависимости от флагов, это может не запускать немедленную запись на диск, а в некоторых случаях может вообще не переходить на диск (хотя, по-видимому, последние не те случаи, которые вас интересуют. в).
Лучшее, что я могу придумать для файлов mmap'd, если это возможно для вас, - это поместить каждый из интересующих файлов на отдельное устройство и использовать статистику устройства для сбора информации об использовании. Вы можете использовать для этого разделы lvm. Однако привязка не будет работать, поскольку она не создает новое блочное устройство.
Если у вас есть файлы на отдельных блочных устройствах, вы можете получать статистику из / sys / block / * или / proc / diskstats.
Возможно, внедрение этого на производственный сервер будет слишком разрушительным, но, возможно, вы сможете его использовать.
ЕСЛИ файлы не сопоставлены, то да, вы можете выбрать здесь одно из других решений.
Я недавно возился с собирать , это отличный инструмент, и его довольно легко установить. Самое интересное, что вы можете узнать, какой процесс является причиной узких мест ввода-вывода. Я бы порекомендовал вам прочитать Использование Collectl , может быть полезно.
Я бы порекомендовал вам проверить http://dag.wieers.com/home-made/dstat/. Этот замечательный инструмент позволяет проверять множество статистических данных.
Я думаю, что iotop - один из лучших инструментов в Linux для выявления узких мест при вводе-выводе.