Linux IO monitoramento por arquivo?

28

Estou interessado em um utilitário ou processo para monitorar o disco IO por arquivo no CentOS.

No Win2008, o utilitário resmon permite esse tipo de pesquisa, mas nenhum dos utilitários do Linux que eu encontrei faz isso (iostat, iotop, dstat, nmon).

Meu interesse em monitorar gargalos de IO em servidores de banco de dados. Com MSSQL, eu encontrei um diagnóstico informativo para saber quais arquivos / espaços de arquivos estão sendo atingidos mais duramente.

    
por MattK 04.11.2011 / 22:50

14 respostas

17

SystemTap é provavelmente sua melhor opção.

Veja como a saída do exemplo iotime.stp se parece com:

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

A desvantagem (além da curva de aprendizado) é que você precisará instalar kernel-debug , o que pode não ser possível em um sistema de produção. No entanto, você pode recorrer a inter-instrumentação onde você compila um módulo em um sistema de desenvolvimento e executa esse .ko no sistema de produção.

Ou se você for impaciente, consulte Capítulo 4. Scripts Úteis do SystemTap do guia para iniciantes.

    
por 05.11.2011 / 01:52
16
Script

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

A saída é assim:

[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

Ou se você optar por exibir apenas o caminho do ponto de montagem:

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

Limitações / erros:

  • AE / S baseada em mmap não aparece porque devname é "N/A"
  • arquivos em tmpfs não aparecem porque devname é "N/A"
  • não importa se as leituras são do cache ou se as gravações são para o buffer

Os resultados dos programas 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 compartilhado:

     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 direta):

     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
    

* Instruções de configuração rápida para o RHEL 6 ou equivalente: yum install systemtap e debuginfo-install kernel

    
por 16.10.2013 / 07:10
9

Você realmente deseja usar blktrace para isso. Veja Visualizando o Linux IO com o Seekwatcher e o blktrace .

Verificarei se posso postar um dos meus exemplos em breve.

Editar:

Você não menciona a distribuição do Linux, mas talvez esse seja um bom caso para um dtrace script no Linux ou até mesmo System Tap , se você estiver usando um sistema semelhante ao RHEL.

    
por 03.10.2013 / 03:26
4

A única ferramenta que conheço que pode monitorar a atividade de E / S por arquivo é inotifywatch . Faz parte do pacote inotify-tools . Infelizmente, isso só lhe dá contagens de operações.

    
por 04.11.2011 / 23:48
4

use o iotop para obter os PIDs de processos que contribuem com alto IO

run strace contra o PID que você gerou, você verá quais arquivos estão sendo acessados por um processo em particular

strace -f -p $PID -e trace=open,read,write
    
por 03.10.2013 / 11:54
4

Por fim, usei o Sysdig para isso

    
por 11.10.2015 / 17:09
3

Você quer dizer algo como iotop ?

    
por 03.10.2013 / 02:43
2

Eu diria que você poderia ter feito a pergunta errada. Se você está procurando gargalos de i / o, pode ser tão importante ver o que está acontecendo no seu disco. Os bancos de dados são notórios por fazer o E / S aleatório, o que pode reduzir significativamente a taxa de transferência, especialmente se você tiver apenas alguns fusos.

O que pode ser mais interessante é ver se você está tendo longos tempos de espera nos próprios discos. você pode fazer isso com collectl através do comando "collectl -sD", que mostrará as estatísticas individuais de desempenho do disco. São --home para transformá-lo em um utilitário top-like. Se houver muitos discos envolvidos, execute-o via colmux: colmux -command "-sD" e ele permitirá que você classifique por uma coluna de sua escolha, mesmo em vários sistemas.

    
por 05.11.2011 / 16:52
2

Você pode monitorar a E / S por dispositivo de bloco (via / proc / diskstats) e por processo (contabilidade io via /proc/$PID/io ou taskstats ), mas não sei como fazer isso por arquivo.

    
por 04.11.2011 / 23:46
0

Embora haja muitas informações boas nas respostas aqui, estou pensando se isso é realmente aplicável?

Se você está falando sobre arquivos nos 10s de gigabytes, constantemente sendo gravados, então, a menos que sejam arquivos de log ou similares que são constantemente adicionados (nesse caso apenas monitorar tamanhos de arquivo), é mais provável que os arquivos sejam mmap'd. Se for esse o caso, a melhor resposta pode ser que você deve parar de procurar a maioria das soluções. A primeira coisa que você deve perguntar a qualquer outra solução proposta é "funciona com o mmap", porque na maioria das vezes não. No entanto, você pode transformar o problema em um dispositivo de bloco em vez de monitorar um arquivo.

Quando um programa pede uma página de um arquivo mmap'd, é apenas referenciar uma localização na memória virtual. Essa página pode ou não estar na memória. Se não for, isso gera uma falha de página, que aciona a página sendo carregada do disco, mas isso acontece no sistema de memória virtual, que não é facilmente vinculado a um processo de aplicativo específico ou a um arquivo específico. Da mesma forma, quando seu aplicativo atualiza uma página mmap'd, dependendo dos sinalizadores, isso pode não acionar uma gravação imediata em disco e, em alguns casos, pode não ir ao disco (embora esses últimos não sejam os casos em que você está interessado em).

O melhor que posso pensar em arquivos mmap'd, se for viável para você, é colocar cada um dos arquivos de interesse em um dispositivo separado e usar as estatísticas do dispositivo para coletar suas informações de uso. Você poderia usar partições lvm para isso. Uma montagem de ligação não funcionará, pois não cria um novo dispositivo de bloco.

Depois de ter seus arquivos em dispositivos de bloco separados, você pode obter estatísticas de / sys / block / * ou / proc / diskstats

Pode ser muito complicado introduzir isso em um servidor de produção, mas talvez você possa utilizá-lo.

SE os arquivos não forem mmapados, então sim, você pode escolher uma das outras soluções aqui.

    
por 18.10.2013 / 11:11
-1

Recentemente, eu estava mexendo com o collectl , ele parece uma ótima ferramenta e bastante simples de instalar. O mais interessante é que você pode descobrir qual é o processo responsável pelos gargalos de IO. Eu recomendo que você leia Usando Collectl , pode ser útil.

    
por 04.11.2011 / 23:03
-1

Recomendamos que você verifique o link . Esta ótima ferramenta permite verificar muitas estatísticas.

    
por 06.11.2011 / 16:10
-1

Pode ser que inotify resolva isso.

A API inotify fornece um mecanismo para monitorar eventos do sistema de arquivos. O Inotify pode ser usado para monitorar arquivos individuais ou para monitorar diretórios. Quando um diretório é monitorado, o inotify retornará eventos para o próprio diretório e para os arquivos dentro do diretório.

Monitore a atividade do sistema de arquivos com o inotify

Referência de inotificação

    
por 12.10.2013 / 11:59
-2

Eu acho que o iotop é uma das melhores ferramentas no Linux para identificar gargalos no IO.

    
por 04.11.2011 / 23:03