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

Мене цікавить утиліта або процес для моніторингу вводу-виводу диска на файл у 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для цього. Див. Розділ Візуалізація IO Linux з Seekwatcher та blktrace .

Я побачу, чи зможу незабаром опублікувати один із своїх прикладів.

Редагувати:

Ви не згадуєте про поширення Linux, але, можливо, це хороший випадок для сценарію dtrace в Linux або навіть System Tap , якщо ви використовуєте систему, схожу на RHEL.

Єдиний інструмент , який я знаю , що може контролювати активність введення / виведення на файл inotifywatch. Це частина inotify-toolsпакету. На жаль, це дає лише кількість операцій.

використовуйте iotop для отримання PID процесів, які сприяють підвищенню IO

Запустіть страйк із створеного вами PID, ви побачите, до яких файлів здійснюється доступ певного процесу

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

Зрештою я використовував для цього Sysdig

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

що може бути цікавіше - дізнатися, чи довго ви чекаєте на самих дисках. це можна зробити за допомогою collectionl за допомогою команди "collectionl -sD", яка покаже окремі показники продуктивності диска. Є --дома, щоб перетворити його на найвищу утиліту. Якщо задіяно багато дисків, запустіть її через colmux: colmux -command "-sD", і це дозволить вам сортувати за вибором стовпця навіть у кількох системах.

Ви можете відстежувати введення / виводу на блок пристроїв (через / proc / дискстати) та за кожним процесом (іо облік через /proc/$PID/ioабо набір завдань ), але я не знаю способу зробити це за файлом.

Можливо, інотифікація вирішить це вирішити.

API inotify забезпечує механізм моніторингу подій файлової системи. Повідомлення можна використовувати для моніторингу окремих файлів або для моніторингу каталогів. Коли моніторинг каталогів, inotify поверне події як для самого каталогу, так і для файлів усередині каталогу.

Відстежуйте активність файлової системи за допомогою inotify

інотифікувати довідник

Хоча тут є багато корисної інформації у відповідях, мені цікаво, чи реально це застосовно?

Якщо ви говорите про файли в 10-ти гігабайт, постійно записуючись у них, то якщо вони не є файлами журналів або подібними, до яких постійно додаються (у такому випадку просто слідкуйте за розмірами файлів), швидше за все, ці файли є mmap'd . Якщо це так, то найкращою відповіддю може бути те, що ви повинні перестати шукати більшість рішень. Перше, що ви повинні запитати у будь-якому іншому запропонованому рішенні, це "чи працює він з mmap", оскільки в основному вони звичні. Однак, можливо, ви зможете перетворити проблему на моніторинг блокового пристрою, а не на моніторинг файлу.

Коли програма запитує сторінку з файлу mmap'd, вона просто посилається на розташування у віртуальній пам'яті. Ця сторінка може бути або не може бути в пам'яті. Якщо це не так, то генерується помилка сторінки, яка запускає завантаження сторінки з диска, але це відбувається в системі віртуальної пам’яті, яка не так легко пов'язана з конкретним процесом подання заявки або конкретним файлом. Аналогічно, коли ваш додаток оновлює сторінку mmap'd, залежно від прапорів, це може не викликати негайне записування на диск, а в деяких випадках взагалі може не переходити на диск (хоча, мабуть, останні не є випадками, які вас цікавлять в).

Найкраще, що я можу придумати для файлів mmap'd, якщо це є життєздатним для вас, - це розмістити кожен із цікавих файлів на окремому пристрої та використовувати статистику пристрою для збору інформації про використання. Ви можете використовувати для цього розділи lvm. Прив’язка кріплення не буде працювати, хоча це не створює новий блок пристрою.

Коли ви матимете свої файли на окремих блокових пристроях, ви можете отримати статистику з / sys / block / * або / proc / diskstats

Це може бути занадто руйнівним, щоб представити це на виробничому сервері, але, можливо, ви можете ним скористатися.

Якщо файли не mmapped, тоді так, ви можете вибрати одне з інших рішень тут.

Нещодавно я розмовляв з collel , це виглядає чудовим інструментом і досить важким для встановлення. Найцікавіше, що ви можете дізнатись, який є відповідальним за вузькі місця ВО. Я рекомендую вам ознайомитися з використанням Collectl , це може бути корисним.

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

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