Linux IO мониторинг на файл?

Меня интересует утилита или процесс для мониторинга дискового ввода-вывода по файлам в 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)

Ограничения / баги:

• MMAP системы ввода / вывода не появляется , потому что devnameЭТО"N/A"
• файлы на TMPFS не показывают, потому что 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 IO с Seekwatcher и blktrace .

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

Редактировать:

Вы не упоминаете о дистрибуции Linux, но, возможно, это хороший случай для сценария dtrace в Linux или даже System Tap , если вы используете RHEL-подобную систему.

Единственный инструмент, который я знаю об этом, может контролировать активность ввода / вывода по файлу inotifywatch. Это часть inotify-toolsпакета. К сожалению, это только дает вам счет операций.

используйте iotop, чтобы получить PID процессов, которые способствуют высокому IO

запустите strace для сгенерированного вами PID, вы увидите, к каким файлам обращается определенный процесс

strace -f -p $PID -e trace=open,read,write

Я в конечном итоге использовал Sysdig для этого

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

Что может быть более интересным, это посмотреть, если у вас есть длительное время ожидания на самих дисках. Вы можете сделать это с помощью collectl с помощью команды "collectl -sD", которая покажет статистику производительности отдельного диска. Есть - чтобы превратить его в топ-утилиту. Если задействовано много дисков, запустите его через colmux: colmux -command "-sD", и он позволит вам сортировать по столбцу по вашему выбору, даже в нескольких системах.

Вы можете отслеживать ввод-вывод для каждого блочного устройства (через / proc / diskstats) и для каждого процесса (учет бухгалтерии через /proc/$PID/ioили taskstats ), но я не знаю, как это сделать для каждого файла.

Может быть, inotify решит решить эту проблему.

API inotify предоставляет механизм для мониторинга событий файловой системы. Notify может использоваться для мониторинга отдельных файлов или для мониторинга каталогов. При мониторинге каталога inotify будет возвращать события для самого каталога и для файлов внутри каталога.

Мониторинг активности файловой системы с помощью inotify

ссылка

Хотя в ответах много полезной информации, мне интересно, действительно ли это применимо?

Если вы говорите о файлах в десятках гигабайт, которые постоянно записываются, то, если они не являются файлами журналов или аналогичными файлами, к которым постоянно добавляются (в этом случае только контролируют размеры файлов), скорее всего, файлы будут mmap'd , Если это так, то лучшим ответом может быть то, что вы должны перестать смотреть на большинство решений. Первое, что вы должны затем спросить о любом другом предложенном решении, это «работает ли оно с mmap», потому что в большинстве случаев это не так. Однако вы можете превратить проблему в мониторинг блочного устройства, а не в мониторинг файла.

Когда программа запрашивает страницу из файла mmap'd, она просто ссылается на местоположение в виртуальной памяти. Эта страница может быть или не быть уже в памяти. Если это не так, тогда генерируется сбой страницы, который вызывает загрузку страницы с диска, но это происходит в системе виртуальной памяти, которую нелегко привязать к конкретному процессу приложения или к определенному файлу. Точно так же, когда ваше приложение обновляет страницу mmap, в зависимости от флагов, это может не вызвать немедленную запись на диск, а в некоторых случаях может вообще не перейти на диск (хотя, вероятно, последние не интересуют вас) в).

Лучшее, что я могу придумать для файлов mmap'd, если это целесообразно для вас, - это поместить каждый интересующий файл на отдельное устройство и использовать статистику устройства для сбора информации об использовании. Вы можете использовать для этого разделы lvm. Тем не менее, связывание не будет работать, так как оно не создает новое блочное устройство.

Если у вас есть файлы на отдельных блочных устройствах, вы можете получить статистику из / sys / block / * или / proc / diskstats

Это может быть слишком разрушительным, чтобы представить это на рабочем сервере, но, возможно, вы можете использовать его.

Если файлы не отображаются, то да, вы можете выбрать одно из других решений здесь.

Недавно я возился с коллекцией , она выглядит великолепно и довольно просто в установке. Самое интересное, что вы можете выяснить, кто является ответственным за узкие места ввода-вывода. Я бы порекомендовал вам прочитать Используя Collectl , это может быть полезно.

Я бы порекомендовал вам проверить http://dag.wieers.com/home-made/dstat/ . Этот отличный инструмент позволяет проверить много статистики.

Я думаю, что iotop является одним из лучших инструментов для Linux для выявления узких мест в IO.