Como posso ver estatísticas de i / o para um processo em execução breve?

Question

Como posso ver estatísticas de i / o para um processo em execução breve?

#1 resposta do (2 votos)
#2 resposta do (1 votos)

5

Para processos longos como o init, posso fazer coisas como

$ cat /proc/[pid]/io

O que posso fazer se eu quiser ver as estatísticas de um processo em execução breve, como um utilitário de linha de comando como o ls? Eu nem sei como ver o pid para um processo tão breve em execução ...

process io statistics process-management

por labyrinth 22.07.2014 / 19:13

2 respostas

1

Você pode iniciar o comando em background e obter seu pid via variável $! .

Exemplo:

$ ls & cat /proc/$!/io
[1] 6410
rchar: 7004
wchar: 0
syscr: 13
syscw: 0
read_bytes: 0
write_bytes: 0
cancelled_write_bytes: 0

por 22.07.2014 / 19:37

Tags process io statistics process-management

Por que o ponto de montagem do meu sistema de arquivos raiz é alterado? Como adicionar diretórios específicos ao caminho de busca “updatedb” (locate)?

score 2 · Accepted Answer

Basicamente, parece que você quer conselhos gerais sobre a criação de perfis de E / S de uma aplicação em tempo de execução. Você está fazendo isso com /proc/$PID/io , o que lhe dará uma idéia de quanto de largura de banda está sendo usada entre disco e memória para o aplicativo. Pesquisando este arquivo pode dar uma idéia aproximada do que o processo está fazendo, mas é uma imagem incompleta, uma vez que só mostra a quantidade de dados que estão sendo empurrados para o disco.

Para resolver seu problema declarado, você basicamente tem as seguintes opções:

Use instrumentação de plataforma. No Linux escrever um script SystemTap é a solução mais completa, mas dependendo de quão hardcore você quer ir, pode ser mais trabalho do que você está realmente disposto a gastar para o benefício desejado.
Use instrumentação baseada em aplicativo. Muitas maneiras de fazer isso, mas o perfil do gprof , é uma opção popular. Alguns aplicativos também podem fornecer sua própria instrumentação, mas você precisa verificar.

Provavelmente, a melhor alternativa é usar ferramentas de instrumentação de plataforma já existentes para alcançar o efeito desejado e tirar o máximo proveito dela.

Não tenho conhecimento de um programa que inicie um aplicativo e faça tudo isso por você (não significa que não haja nenhum meio, apenas que eu não tenha ouvido falar dele), então sua melhor aposta é apenas começar a coletar informações de todo o sistema e filtrar apenas o PID que você está preocupado após o fato (para obter uma amostra completa).

Antes de tudo, gostaria de ativar a auditoria de execve chamadas para que você possa salvar o PID do aplicativo que está sendo desativado. Depois de ter o PID, você pode remover a auditoria.

Execute mount debugfs -t debugfs /sys/kernel/debug para obter o debugfs em execução, para que você possa executar o blktrace .

No meu sistema, corri blktrace -d /dev/sda -a read -a write -o - | blkparse -i - , mas você pode ajustar de acordo. Aqui está um exemplo de saída do blktrace:

8,0   15        3 1266874889.709440165 32679  Q   W 20511277 + 8 [rpc.mountd]

Na saída acima, a quinta coluna ( 32679 ) é o PID associado ao aplicativo que executa a gravação. As partes que nos interessam são o Q (tipo de evento, enfileirado) o W (campo RWBS, W significa que é uma gravação, pois não há S nesse campo, a implicação é que era um assíncrono um.) e o 20511277 + 8 (a operação começa no número de bloco 20511277 e vai para outros oito blocos). Determinar os tamanhos de leitura / gravação deve apenas adicionar os blocos juntos e multiplicar por tamanho de bloco.

blktrace também informará sobre mais do que apenas a taxa de transferência, ele também permitirá que você veja se há alguma coisa acontecendo com as mesclagens com as quais você se importa.

Uma vez que você tenha o blktrace rodando, você pode gerar o processo usando strace -c que lhe dará uma sensação da latência média associada com cada chamada de sistema (incluindo read e write operações). Dependendo de quão confiável cada chamada precisa ser de latência pode ser importante, ela também pode dizer mais sobre o que o aplicativo está fazendo (para apontar áreas para explorar o ajuste) sem ter nenhuma instrumentação de aplicativo em andamento.

Entre os dois, você deve obter uma boa amostra do que seu programa está fazendo sem perder nenhum dado ou, possivelmente, incluir a E / S de outros aplicativos. Obviamente, há mais maneiras de fazer isso do que o que descrevi, mas é assim que resolvi o problema.

Também deve ser possível coletar medidas de latência relacionadas a E / S mexendo com as opções de saída de blkparse , por exemplo. Eu simplesmente não fiz porque não brinquei com eles o suficiente.