Como verificar a utilização de E / S do disco por processo

Estou tendo um problema com um sistema Linux parado e eu encontrei o sysstat / sar para relatar picos enormes na utilização de E / S de disco, tempo médio de serviço e tempo médio de espera no momento da paralisação do sistema.

Como eu poderia determinar qual processo está causando esses picos na próxima vez que acontecer?
É possível fazer com sar (ou seja: posso encontrar essas informações nos arquivos sar já gravados?

A saída para "sar -d", paralisação do sistema ocorreu por volta das 12,58 às 13,01 da tarde.

12:40:01          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
12:40:01       dev8-0     11.57      0.11    710.08     61.36      0.01      0.97      0.37      0.43
12:45:01       dev8-0     13.36      0.00    972.93     72.82      0.01      1.00      0.32      0.43
12:50:01       dev8-0     13.55      0.03    616.56     45.49      0.01      0.70      0.35      0.47
12:55:01       dev8-0     13.99      0.08    917.00     65.55      0.01      0.86      0.37      0.52
13:01:02       dev8-0      6.28      0.00    400.53     63.81      0.89    141.87    141.12     88.59
13:05:01       dev8-0     22.75      0.03    932.13     40.97      0.01      0.65      0.27      0.62
13:10:01       dev8-0     13.11      0.00    634.55     48.42      0.01      0.71      0.38      0.50

Esta é uma pergunta de acompanhamento para um encadeamento iniciado ontem: Picos repentinos de carga e espera de bloco de disco , espero que esteja tudo bem que eu criei um novo tópico / pergunta sobre o assunto, pois ainda não consegui resolver o problema.

Se você tiver a sorte de acompanhar o próximo período de pico de utilização, poderá estudar as estatísticas de E / S por processo interativamente, usando o iotop .

Você pode usar o pidstat para imprimir estatísticas acumuladas de io por processo a cada 20 segundos com este comando:

# pidstat -dl 20

Cada linha terá colunas seguintes:

• PID - ID do processo
• kB_rd / s - Número de kilobytes que a tarefa causou a leitura do disco por segundo.
• kB_wr / s - Número de kilobytes que a tarefa causou ou deve causar a gravação no disco por segundo.
• kB_ccwr / s - Número de kilobytes cuja gravação no disco foi cancelada pela tarefa. Isso pode ocorrer quando a tarefa trunca algum pagecache sujo. Nesse caso, algum pedido de veiculação cuja outra tarefa tenha sido contabilizada não estará acontecendo.
• Comando - O nome do comando da tarefa.

A saída é assim:

05:57:12 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:57:32 PM       202      0.00      2.40      0.00  jbd2/sda1-8
05:57:32 PM      3000      0.00      0.20      0.00  kdeinit4: plasma-desktop [kdeinit]              

05:57:32 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:57:52 PM       202      0.00      0.80      0.00  jbd2/sda1-8
05:57:52 PM       411      0.00      1.20      0.00  jbd2/sda3-8
05:57:52 PM      2791      0.00     37.80      1.00  kdeinit4: kdeinit4 Running...                   
05:57:52 PM      5156      0.00      0.80      0.00  /usr/lib64/chromium/chromium --password-store=kwallet --enable-threaded-compositing 
05:57:52 PM      8651     98.20      0.00      0.00  bash 

05:57:52 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:58:12 PM       202      0.00      0.20      0.00  jbd2/sda1-8
05:58:12 PM      3000      0.00      0.80      0.00  kdeinit4: plasma-desktop [kdeinit]              

Nada supera o monitoramento contínuo, você simplesmente não pode recuperar dados sensíveis ao tempo após o evento ...

No entanto, existem algumas coisas que você pode verificar para implicar ou eliminar - /procé seu amigo.

sort -n -k 10 /proc/diskstats
sort -n -k 11 /proc/diskstats

Os campos 10, 11 são setores escritos acumulados e tempo acumulado (ms). Isso mostrará suas partições quentes do sistema de arquivos.

cut -d" " -f 1,2,42 /proc/*/stat | sort -n -k +3

Esses campos são PID, comando e ticks de espera de E / S cumulativos. Isso mostrará seus processos quentes, embora apenas se eles ainda estiverem em execução . (Você provavelmente deseja ignorar os threads de diário do sistema de arquivos.)

A utilidade do exposto acima depende do tempo de atividade, da natureza de seus processos de execução longa e de como seus sistemas de arquivos são usados.

Advertências: não se aplica a kernels anteriores a 2,6; verifique sua documentação se não tiver certeza.

(Agora faça um favor ao seu futuro, instale Munin / Nagios / Cacti / qualquer que seja ;-)

Use atop. ( http://www.atoptool.nl/ )

Escreva os dados em um arquivo compactado que atoppossa ser lido posteriormente em um estilo interativo. Faça uma leitura (delta) a cada 10 segundos. faça 1080 vezes (3 horas; por isso, se você esquecer o arquivo de saída, você não ficará sem disco):

$ atop -a -w historical_everything.atop 10 1080 &

Depois que algo ruim acontece novamente:

(mesmo que ainda esteja sendo executado em segundo plano, é anexado a cada 10 segundos)

% atop -r historical_everything.atop

Desde que você disse IO, eu pressionaria 3 teclas: tdD

t - move forward to the next data gathering (10 seconds)
d - show the disk io oriented information per process
D - sort the processes based on disk activity
T - go backwards 1 data point (10 seconds probably)
h - bring up help
b - jump to a time (nearest prior datapoint) - e.g. b12:00 - only jumps forward
1 - display per second instead of delta since last datapiont in the upper half of the display

Use btrace. É fácil de usar, por exemplo btrace /dev/sda. Se o comando não estiver disponível, provavelmente estará disponível no pacote blktrace .

EDIT : Como o debugfs não está ativado no kernel, você pode tentar date >>/tmp/wtf && ps -eo "cmd,pid,min_flt,maj_flt" >>/tmp/wtfou algo semelhante. As falhas na página de log não são, obviamente, iguais a usar o btrace, mas se você tiver sorte, PODE fornecer algumas dicas sobre os processos que exigem mais disco. Eu apenas tentei aquele em um dos meus servidores mais intensivos de E / S e a lista incluía os processos que eu sei que estão consumindo muitas E / S.