☰

Medir latências de E/S de disco de um processo em execução

tag-icon • tag-icon linux strace perf-event dtrace
Medir latências de E/S de disco de um processo em execução

Estou tentando medir as latências de E/S 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, como emeste artigo Joyent), mas meu aplicativo está sendo executado no Linux. Meu primeiro pensamento foi tentar perf, e consigo obter contadores, mas não consigo encontrar nenhuma 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 IO do disco (este sistema também possui uma interface de rede ocupada).

Existe alguma maneira de fazer isso no Linux?

Responder1

Na verdade, isso é complicado. Mas há dicas:

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

  • Aprendertraço preto. Você pode analisar sua saída, em teoria. Isso representará mais latência do dispositivo (tempo de serviço) do quetempo de respostaprograma continue read().

Sim stracepode não ser apropriado, pois rastreará tudo (todos os syscalls, mesmo quando você usa -efiltro) e carregará o servidor e reduzirá consideravelmente o processo. Perfé uma ferramenta muito obscura, você pode ter momentos em que pensa que entendeu sua saída, mas na verdade não entendeu, e seu conjunto de recursos depende muito da versão do kernel. Basicamente e atualmente perfé adequado para medirTempo de CPU(ciclos), e [ainda] inadequado para medirtempos 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 algo. (Veja também em perf-scripts ( perf script -l) se você quiser investigar mais a fundo.)

  • Pode ser que você consiga obter algo derastreamento. Leia este artigohttp://lwn.net/Articles/370423/(E isso para ointrodução.) Como posso ver, você pode limitar o rastreamento por piduma função e, em seguida, rastrear 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();

Responder2

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

Usando o recurso de despejo de bloco e um pouco de script, uma visão geral de alto nível sobre as ações de E/S que os processos estão produzindo pode ser obtida. Para fazer isso, complete o seguinte:

Desative o registro do sistema por um curto período de tempo (para não atrapalhar a captura de dados):

# serviço syslog stop # echo 1 > /proc/sys/vm/block_dump

Aguarde até que o problema de alto iowait ocorra, depois de reativar o syslog (ou rsyslog, se estiver usando isso) e desative o despejo de bloco:

# início do syslog de serviço # echo 0 > /proc/sys/vm/block_dump

Usando o seguinte comando, analise a saída dmesg para ações READ/WRITE/dirtied sendo emitidas por determinados processos:

# dmesg | awk '/(READ|WRITE|dirtied)/ {atividade[$1]++} END {para (x em atividade) print x, atividade[x]}'| classificar -nr -k 2,2| cabeça -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 náutilos (24498): 46

O exemplo de saída acima mostra os 10 principais processos que emitiram operações READ, WRITE e sujas durante o tempo em que o dump do bloco estava em execução. Usando esses dados, uma visão geral de alto nível do número de processos operacionais que estão sendo emitidos pode ser obtida e pode ajudar a determinar se um único processo está contribuindo fortemente para o iowait.

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

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

informação relacionada