Mede as latências do IO do disco de um processo em execução

Question

Estou tentando medir as latências de IO do disco de um processo em execução para fazer um histograma.

Eu poderia fazer isso com o DTrace em sistemas operacionais que o fornecem (por exemplo, em este documento da Joyent ), mas meu aplicativo está sendo executado no Linux. Meu primeiro pensamento foi tentar perf , e eu posso obter contadores, mas não consigo encontrar qualquer maneira de obter deltas de tempo. Posso obter deltas de tempo com strace (por exemplo, strace -e read -T ), mas não tenho certeza se posso restringir o rastreamento ao disco IO (esse sistema também tem uma interface de rede ocupada).

Existe alguma maneira de fazer isso no Linux?

    

Answer 1

Isso é realmente complicado. Mas há dicas:

• Aprenda sobre o SystemTap, este é o análogo do Linux do DTrace. Eu acho que eles podem até ter scripts de exemplo para tarefas similares.

• Aprenda blktrace . Você pode ser capaz de analisar sua saída, em teoria. Isso será mais latência de dispositivo (tempo de serviço) do que o tempo de resposta chegar em read() .

Sim strace pode não ser apropriado, pois rastreará tudo (todos os syscalls, mesmo quando você usar o filtro -e ) e carregará o servidor e o processo mais lento consideravelmente. Perf é uma ferramenta muito obscura, você pode ter momentos em que acha que entende sua saída, mas na verdade não o fez, e seu conjunto de recursos depende muito da versão do kernel. Basicamente e atualmente perf é adequado para medir tempo de CPU (ciclos), e [ainda] inadequado para medir tempos de resposta (o que você realmente precisa). Ouvi dizer que eles queriam implementar algo para facilitar isso, então em kernels de desenvolvimento muito recentes pode haver alguma coisa. (Veja também em perf-scripts ( perf script -l ) se você investigar mais.)

• Pode ser que você consiga algo do ftrace . Leia este artigo link (E isso para o intro .) Como eu posso ver, você pode limitar o rastreio por pid e function, então rastreie com algo como sys_read . Eu tentei isso como exemplo para você:

  # mount -t debugfs debugfs /sys/kernel/debug # if it's not already mounted
  # cd /sys/kernel/debug/tracing
  # echo $$ > set_ftrace_pid  # pid of process to trace
  # echo sys_read sys_write > set_ftrace_filter
  # echo function_graph > current_tracer
  # head trace
  
  # tracer: function_graph
  #
  # CPU  DURATION                  FUNCTION CALLS
  # |     |   |                     |   |   |   |
   0)   8.235 us    |  sys_write();
   0)   3.393 us    |  sys_write();
   0) ! 459859.3 us |  sys_read();
   0)   6.289 us    |  sys_write();
   0)   8.773 us    |  sys_write();
   0) ! 1576469 us |  sys_read();
  

Answer 2

Se você estiver interessado apenas no número de chamadas de "leitura" ou "gravação" para bloquear dispositivos este é o POP da Red Hat para determinar que .

Using the block dump feature and a bit of scripting a high level overview about the I/O actions processes are producing can be gathered. To do so, complete the following:

Disable system logging for a short period of time (so it doesn't get in the way of the data capture):

# service syslog stop # echo 1 > /proc/sys/vm/block_dump

Wait for the high iowait issue to occur, once it has past re-enable syslog (or rsyslog if using that), and disable the block dump:

# service syslog start # echo 0 > /proc/sys/vm/block_dump

Using the following command parse the dmesg output for READ/WRITE/dirtied actions being issued by certain processes:

# dmesg | awk '/(READ|WRITE|dirtied)/ {activity[$1]++} END {for (x in activity) print x, activity[x]}'| sort -nr -k 2,2| head -n 10

kjournald(1425): 5984 kjournald(3681): 1269 pdflush(27301): 725 iostat(2913): 134 crond(26919): 61 crond(28985): 60 crond(7026): 54 sshd(28175): 50 sshd(15388): 50 nautilus(24498): 46

The example output above shows the top 10 processes that issued READ, WRITE and dirtied operations during the time the block dump was running. Using this data a high level overview of the number of operations processes are issuing can be gathered and it can help determine if a single process is contributing highly to iowait.

Existem também várias ferramentas de linha de comando como atop e iotop que fornecem estatísticas de iowait por processo e podem ser executadas como parte de um script (o que significa que eles têm modos em lote que podem fazer uma única iteração para determinados PIDs).

EDITAR: Fazendo mais pesquisas, parece que você pode obter o iowait por processo em / proc / $ pid / stat (procure por "Atrasos de E / S do bloco agregado")