Monitoreo IO de Linux por archivo?

Estoy interesado en una utilidad o un proceso para supervisar IO de disco por archivo en CentOS.

En Win2008, la utilidad resmon permite este tipo de desglose, pero ninguna de las utilidades Linux que he encontrado hacer esto (iostat, iotop, dstat, nmon).

Mi interés en supervisar los cuellos de botella de IO en los servidores de base de datos. Con MSSQL, he encontrado un diagnóstico informativo para saber qué archivos / espacios de archivos se están golpeando con más fuerza.

SystemTap es probablemente su mejor opción.

A continuación se muestra cómo se muestra el resultado del ejemplo 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 

La desventaja (aparte de la curva de aprendizaje) es que necesitará instalar kernel-debug , lo cual puede no ser posible en un sistema de producción. Sin embargo, puede recurrir a la instrumentación cruzada en la que compile un módulo en un sistema de desarrollo y ejecute .ko en el sistema de producción.

O si usted es impaciente, mire el capítulo 4. Scripts útiles de SystemTap de la guía de los principiantes.

Script de 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) } 

La salida se ve así:

 [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 

O si elige mostrar sólo la ruta desde el punto de montaje:

 [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) 

Limitaciones / errores:

  • La E / S basada en mmap no aparece porque devname es "N/A"
  • Los archivos de tmpfs no se muestran porque devname es "N/A"
  • No importa si las lecturas son de la caché o las escrituras son para el buffer

Los resultados de los programas de Matthew Ife :

  • Para mmaptest privado:

      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 
  • Para mmaptest compartido:

      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 
  • Para diotest (E / S directa):

      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 

* Instrucciones de configuración rápida para RHEL 6 o equivalente: yum install systemtap y debuginfo-install kernel

Realmente querrías usar blktrace para esto. Consulte Visualización de Linux IO con Seekwatcher y blktrace .

Voy a ver si puedo publicar uno de mis ejemplos pronto.


Editar:

Usted no menciona la distribución de Linux, pero tal vez este es un buen caso para una secuencia de comandos de dtrace en Linux o incluso Tap de sistema , si está utilizando un sistema similar a RHEL.

La única herramienta que conozco que puede monitorear la actividad de E / S por archivo es inotifywatch . Es parte del paquete inotify-tools . Por desgracia, sólo te da cuenta de operación.

Use iotop para obtener los PIDs de procesos que contribuyen con IO alto

Run strace contra el PID que generó, verá qué archivos están siendo accedidos por un proceso en particular

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

¿Te refieres a algo como iotop ?

Yo diría que usted podría haber hecho la pregunta equivocada. Si está buscando cuellos de botella de entrada / salida, puede ser tan importante ver lo que está sucediendo en su disco. Db son notorios para hacer al azar i / o que puede reducir significativamente el rendimiento, especialmente si sólo tiene unos pocos husos.

Lo que puede ser más interesante es ver si tienes largos tiempos de espera en los discos. Puede hacerlo con collectl a través del comando "collectl -sD", que mostrará estadísticas de rendimiento de disco individuales. Are –home para convertirlo en una utilidad de primer nivel. Si hay muchos discos involucrados, ejecútelo a través de colmux: colmux -command "-sD" y le permitirá ordenar por una columna de su elección, incluso a través de múltiples sistemas.

Usted puede monitorear el dispositivo de entrada / salida (por medio de / proc / diskstats) y por proceso (io contabilidad a través de /proc/$PID/io o taskstats ), pero no sé de una manera de hacerlo por archivo.

Eventualmente utilicé Sysdig para esto

Si bien hay mucha información buena en las respuestas aquí, me pregunto si es realmente aplicable?

Si usted está hablando de archivos en los 10s de gigabytes, constantemente escribiendo en, a menos que sean archivos de registro o similares que constantemente se anexan a (en cuyo caso sólo monitorear el tamaño de los archivos), es más probable que los archivos son mmap'd . Si ese es el caso, entonces la mejor respuesta puede ser que usted debe dejar de buscar en la mayoría de las soluciones. Lo primero que debe pedir de cualquier otra solución propuesta es "funciona con mmap", porque la mayoría de ellos wont.However, puede ser capaz de convertir el problema en la supervisión de un dispositivo de bloque en lugar de controlar un archivo.

Cuando un programa pide una página de un archivo mmap'd, sólo hace referencia a una ubicación en la memoria virtual. Esa página puede o no estar ya en memoria. Si no lo es, entonces genera un fallo de página, lo que desencadena la carga de la página desde el disco, pero eso sucede dentro del sistema de memoria virtual, que no se enlaza fácilmente con un proceso de aplicación específico o con un archivo específico. Del mismo modo, cuando su aplicación actualiza una página mmap'd, dependiendo de las banderas, que no puede desencadenar una inmediata escribir en el disco, y en algunos casos no puede ir al disco en absoluto (aunque presumiblemente los últimos no son los casos que están interesados en).

Lo mejor que puedo pensar de los archivos mmap'd, si es viable para usted, es poner cada uno de los archivos de interés en un dispositivo separado, y usar las estadísticas del dispositivo para recopilar su información de uso. Puede utilizar particiones lvm para esto. Sin embargo, un montaje de enlace no funcionará, ya que no crea un nuevo dispositivo de bloque.

Una vez que tenga sus archivos en dispositivos de bloque separados, puede obtener estadísticas de / sys / block / * o / proc / diskstats

Podría ser demasiado perturbador introducir esto a un servidor de producción, pero tal vez usted puede hacer uso de él.

SI los archivos no están mapeados, entonces sí, puede elegir una de las otras soluciones aquí.

Recientemente estaba jugando con collectl , se ve una gran herramienta, y bastante straigforward para instalar. Lo más interesante es que puede averiguar cuál es el proceso responsable de los cuellos de botella de E / S. Te recomiendo que leas Using Collectl , puede ser útil.

Te recomiendo que consultes http://dag.wieers.com/home-made/dstat/ . Esta gran herramienta permite comprobar un montón de estadísticas.

Puede ser inotify resolverá resolver esto.

La API inotify proporciona un mecanismo para supervisar los eventos del sistema de archivos. Inotify puede utilizarse para monitorear archivos individuales o para supervisar directorios. Cuando se supervisa un directorio, inotify devolverá eventos para el propio directorio y para los archivos dentro del directorio.

Supervisar la actividad del sistema de archivos con inotify

Inotify Referencia

Creo que iotop es una de las mejores herramientas de Linux para identificar cuellos de botella en IO.