Determinación del archivo específico responsable de E / S alta

Este es un problema simple pero la primera vez que he tenido que solucionarlo: encontrar qué archivos / inodos específicos son los objetivos de la mayoría de las E / S. Me gustaría poder obtener una visión general del sistema, pero si tengo que dar un PID o TID, estoy de acuerdo con eso.

Me gustaría ir sin tener que hacer un straceprograma en el que aparece iotop. Preferiblemente, usando una herramienta en la misma línea que iotoppero que detalla por archivo. Puedo usar lsofpara ver qué archivos ha abierto Mailman, pero no indica qué archivo está recibiendo E / S o cuánto.

He visto en otros lugares donde se sugirió su uso, auditdpero preferiría no hacerlo, ya que incluiría la información en nuestros archivos de auditoría, que usamos para otros fines y esto parece un problema que debería poder investigar. De este modo.

El problema específico que tengo ahora es que las instantáneas de LVM se llenan demasiado rápido. Desde entonces, he resuelto el problema, pero me gustaría haberlo solucionado de esta manera en lugar de simplemente hacer un lsen todos los descriptores de archivos abiertos /proc/<pid>/fdpara ver cuál crecía más rápido.

Hay varios aspectos de esta pregunta que se han abordado parcialmente a través de otras herramientas, pero no parece haber una sola herramienta que brinde todas las funciones que está buscando.

iotop

Esta herramienta muestra qué procesos están consumiendo más E / S. Pero carece de opciones para mostrar nombres de archivo específicos.

$ sudo iotop
Total DISK READ:       0.00 B/s | Total DISK WRITE:       0.00 B/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                                        
    1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % init
    2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
    3 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/0]
    5 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kworker/u:0]
    6 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/0]
    7 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [watchdog/0]

De forma predeterminada, hace lo que hace regularmente toppara los procesos que compiten por el tiempo de la CPU, excepto las E / S de disco. Puede convencerlo para que le brinde una vista de 30,000 pies usando el -ainterruptor para que muestre una acumulación por proceso, con el tiempo.

$ sudo iotop -a
Total DISK READ:       0.00 B/s | Total DISK WRITE:       0.00 B/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                                        
  258 be/3 root          0.00 B    896.00 K  0.00 %  0.46 % [jbd2/dm-0-8]
22698 be/4 emma          0.00 B     72.00 K  0.00 %  0.00 % chrome
22712 be/4 emma          0.00 B    172.00 K  0.00 %  0.00 % chrome
 1177 be/4 root          0.00 B     36.00 K  0.00 %  0.00 % cupsd -F
22711 be/4 emma          0.00 B    120.00 K  0.00 %  0.00 % chrome
22703 be/4 emma          0.00 B     32.00 K  0.00 %  0.00 % chrome
22722 be/4 emma          0.00 B     12.00 K  0.00 %  0.00 % chrome

Herramientas i * (inotify, iwatch, etc.)

Estas herramientas proporcionan acceso a los eventos de acceso a archivos, sin embargo, deben estar específicamente dirigidas a directorios o archivos específicos. Por lo tanto, no son tan útiles cuando intentan rastrear el acceso a un archivo no autorizado por un proceso desconocido, al depurar problemas de rendimiento.

Además, el inotifymarco no proporciona detalles sobre los archivos a los que se accede. Solo está disponible el tipo de acceso, de modo que no se dispone de información sobre la cantidad de datos que se mueven de un lado a otro, utilizando estas herramientas.

iostat

Muestra el rendimiento general (lecturas y escrituras) en función del acceso a un dispositivo determinado (disco duro) o partición. Pero no proporciona ninguna idea de qué archivos están generando estos accesos.

$ iostat -htx 1 1
Linux 3.5.0-19-generic (manny)  08/18/2013  _x86_64_    (3 CPU)

08/18/2013 10:15:38 PM
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.41    0.00    1.98    0.11    0.00   79.49

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda
                  0.01     0.67    0.09    0.87     1.45    16.27    37.06     0.01   10.92   11.86   10.82   5.02   0.48
dm-0
                  0.00     0.00    0.09    1.42     1.42    16.21    23.41     0.01    9.95   12.22    9.81   3.19   0.48
dm-1
                  0.00     0.00    0.00    0.02     0.01     0.06     8.00     0.00  175.77   24.68  204.11   1.43   0.00

blktrace

Esta opción tiene un nivel demasiado bajo. Carece de visibilidad sobre a qué archivos y / o inodos se está accediendo, solo números de bloque sin procesar.

$ sudo blktrace -d /dev/sda -o - | blkparse -i -
  8,5    0        1     0.000000000   258  A WBS 0 + 0 <- (252,0) 0
  8,0    0        2     0.000001644   258  Q WBS [(null)]
  8,0    0        3     0.000007636   258  G WBS [(null)]
  8,0    0        4     0.000011344   258  I WBS [(null)]
  8,5    2        1 1266874889.709032673   258  A  WS 852117920 + 8 <- (252,0) 852115872
  8,0    2        2 1266874889.709033751   258  A  WS 852619680 + 8 <- (8,5) 852117920
  8,0    2        3 1266874889.709034966   258  Q  WS 852619680 + 8 [jbd2/dm-0-8]
  8,0    2        4 1266874889.709043188   258  G  WS 852619680 + 8 [jbd2/dm-0-8]
  8,0    2        5 1266874889.709045444   258  P   N [jbd2/dm-0-8]
  8,0    2        6 1266874889.709051409   258  I  WS 852619680 + 8 [jbd2/dm-0-8]
  8,0    2        7 1266874889.709053080   258  U   N [jbd2/dm-0-8] 1
  8,0    2        8 1266874889.709056385   258  D  WS 852619680 + 8 [jbd2/dm-0-8]
  8,5    2        9 1266874889.709111456   258  A  WS 482763752 + 8 <- (252,0) 482761704
...
^C
...
Total (8,0):
 Reads Queued:           0,        0KiB  Writes Queued:           7,       24KiB
 Read Dispatches:        0,        0KiB  Write Dispatches:        3,       24KiB
 Reads Requeued:         0       Writes Requeued:         0
 Reads Completed:        0,        0KiB  Writes Completed:        5,       24KiB
 Read Merges:            0,        0KiB  Write Merges:            3,       12KiB
 IO unplugs:             2           Timer unplugs:           0

Throughput (R/W): 0KiB/s / 510KiB/s
Events (8,0): 43 entries
Skips: 0 forward (0 -   0.0%)

fatrace

Esta es una nueva adición al kernel de Linux y una bienvenida, por lo que solo está en distribuciones más nuevas como Ubuntu 12.10. A mi sistema Fedora 14 le faltaba 8-).

Proporciona el mismo acceso que puede obtener inotifysin tener que apuntar a un directorio o archivos en particular.

$ sudo fatrace
pickup(4910): O /var/spool/postfix/maildrop
pickup(4910): C /var/spool/postfix/maildrop
sshd(4927): CO /etc/group
sshd(4927): CO /etc/passwd
sshd(4927): RCO /var/log/lastlog
sshd(4927): CWO /var/log/wtmp
sshd(4927): CWO /var/log/lastlog
sshd(6808): RO /bin/dash
sshd(6808): RO /lib/x86_64-linux-gnu/ld-2.15.so
sh(6808): R /lib/x86_64-linux-gnu/ld-2.15.so
sh(6808): O /etc/ld.so.cache
sh(6808): O /lib/x86_64-linux-gnu/libc-2.15.so

Lo anterior le muestra la identificación del proceso que está accediendo al archivo y a qué archivo está accediendo, pero no le da ningún uso general de ancho de banda, por lo que cada acceso es indistinguible de cualquier otro acceso.

¿Entonces lo que hay que hacer?

La fatraceopción muestra lo más prometedor para FINALMENTE proporcionar una herramienta que puede mostrar el uso agregado de E / S de disco en función de los archivos a los que se accede, en lugar de los procesos que acceden.

Referencias

• fatrace: informe de eventos de acceso a archivos de todo el sistema
• fatrace - informa eventos de acceso a archivos de todo el sistema
• Otro nuevo ABI para fanotify
• Guía del usuario de blktrace

Todavía no he recibido una respuesta, pero escribí este script (al final) y parece hacer lo que quiero. No lo he probado en otros sistemas y es específico de Linux.

Básicamente, solo se envuelve stracedurante 30 segundos, filtra las llamadas al sistema relacionadas con el archivo y hace un esfuerzo para eliminar el nombre del archivo. Cuenta el número de ocurrencias de ese archivo en el stracey presenta un resumen paginado al usuario. No es perfecto, pero la cantidad de llamadas del sistema a un archivo en particular puede tener una correlación débil con la cantidad de E / S que está realizando.

No lo he probado completamente, pero si no funciona fuera de la caja, debería darles a las personas un lugar para comenzar. Si se desarrolla más, puede ser recomendable volver a escribir esto en un lenguaje de nivel superior como python .

Si no recibo una respuesta dentro de una semana de una forma menos casera de hacer esto (incluso si es otra herramienta que solo cuenta las E / S de un proceso en particular), aceptaré esto como mi respuesta para la posteridad.

Guión:

#!/bin/bash

####
# Creates files underneath /tmp
# Requires commands: timeout  strace  stty
####
#
# All commands are GNU unless otherwise stated
#
##########################################################


####
## Initialization
####

outputFile=/tmp/out.$RANDOM.$$
uniqueLinesFile=/tmp/unique.$RANDOM.$$
finalResults=/tmp/finalOutput.txt.$$

if [ $# -ne 1 ]; then
    echo "USAGE: traceIO [PID]" >&2
    exit 2
fi

if ! [[ "$1" =~ ^[0-9]+$ ]]; then
    echo "USAGE: traceIO [PID]" >&2
    echo -e "\nGiven Process ID is not a number." >&2
    exit 2
fi

if [ ! -e /proc/$1 ]; then
    echo "USAGE: traceIO [PID]" >&2
    echo -e "\nThere is no process with $1 as the PID." >&2
    exit 2
fi

if [[ "x$PAGER" == "x" ]]; then

   for currentNeedle in less more cat; do

      which $currentNeedle >/dev/null 2>&1

      if [ $? -eq 0 ]; then
         PAGER=$currentNeedle
         break;
      fi

   done

  if [[ "x$PAGER" == "x" ]]; then

     echo "Please set \$PAGER appropriately and re-run" >&2
     exit 1

  fi

fi

####
## Tracing
####

echo "Tracing command for 30 seconds..."

timeout 30 strace -e trace=file -fvv -p $1 2>&1 | egrep -v -e "detached$" -e "interrupt to quit$" | cut -f2 -d \" > $outputFile

if [ $? -ne 0 ]; then
   echo -e "\nError performing Trace. Exiting"
   rm -f $outputFile 2>/dev/null
   exit 1
fi

echo "Trace complete. Preparing Results..."

####
## Processing
####

sort $outputFile | uniq > $uniqueLinesFile

echo -e "\n--------  RESULTS --------\n\n  #\t Path " > $finalResults
echo -e " ---\t-------" >> $finalResults

while IFS= read -r currentLine; do

   echo -n $(grep -c "$currentLine" "$outputFile")
   echo -e "\t$currentLine"

done < "$uniqueLinesFile" | sort -rn >> $finalResults

####
## Presentation
####

resultSize=$(wc -l $finalResults | awk '{print $1}')
currentWindowSize=$(stty size | awk '{print $1}')

  # We put five literal lines in the file so if we don't have more than that, there were no results
if [ $resultSize -eq 5 ]; then

   echo -e "\n\n No Results found!"

elif [ $resultSize -ge $currentWindowSize ] ; then

   $PAGER $finalResults

else

   cat $finalResults

fi

  # Cleanup
rm -f $uniqueLinesFile $outputFile $finalResults

Puedes usar iwatch usando iWatch

iWatch es muy simple de usar, supongamos que desea ver el cambio en el sistema de archivos / etc, solo necesita ejecutarlo en la consola

$ iwatch /etc

e iwatch te dirá si algo cambia en este directorio. Y si quieres ser notificado por correo electrónico:

$ iwatch -m [email protected] /etc

En este caso, el administrador recibirá una notificación por correo electrónico (tal vez pueda usar su cuenta de puerta de enlace de SMS, por lo que se alarmará inmediatamente en cualquier momento y en cualquier lugar). Y si desea monitorear muchos directorios de diferencia, puede usar un archivo de configuración. Este archivo de configuración es un archivo xml con una estructura fácil de entender.