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

Question

Estou tendo um problema com um sistema Linux paralisado e descobri que sysstat / sar relata picos enormes na utilização de E / S de disco, tempo médio de serviço e tempo de espera médio no momento da paralisação do sistema.

Como eu poderia determinar qual processo está causando esses picos na próxima vez que isso acontecer?
É possível fazer com o sar (ie: posso encontrar essa informação dos arquivos sar gravados da alreade?

A saída para "sar -d", stall do sistema, ocorreu por volta de 12.58-13.01pm.

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 de um tópico que iniciei ontem: Picos repentinos em carga e espera de bloqueio de disco , espero que tenha sido ok que criei um novo tópico / pergunta sobre o assunto, já que ainda não consegui resolver o problema.

    

Answer 1

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

    

Answer 2

Você pode usar o pidstat para imprimir estatísticas cumulativas do 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 serem lidos do disco por segundo.
• kB_wr / s - Número de kilobytes que a tarefa causou ou deve ser gravado em 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, algumas O / I que outra tarefa foi contabilizada não estarão acontecendo.
• Command - 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]              

    

Answer 3

Nada é melhor que o monitoramento contínuo, você simplesmente não consegue obter dados sensíveis ao tempo de volta após o evento ...

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

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

Os campos 10, 11 s sectores escritos acumulados e escrita de tempo acumulado (ms). Isto irá mostrar as suas partições do sistema de arquivos.

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

Esses campos são PID, command e cumulative IO-wait ticks. Isso mostrará seus processos ativos, embora somente se eles ainda estiverem em execução . (Você provavelmente vai querer ignorar seus threads de journalamento do sistema de arquivos.)

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

Advertências: não se aplica a kernels pré-2.6, verifique sua documentação se não tiver certeza.

(Agora vá e faça um favor a si mesmo, instale Munin / Nagios / Cacti / whatever; -)

    

Answer 4

Use atop . ( link )

Grave os dados em um arquivo compactado que atop possa ler mais tarde em um estilo interativo. Faça uma leitura (delta) a cada 10 segundos. faça isso 1080 vezes (3 horas; portanto, se você esquecer, o arquivo de saída não o deixará 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, ele é anexado a cada 10 segundos)

% atop -r historical_everything.atop

Desde que você disse IO, eu iria bater 3 chaves: 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

    

Answer 5

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

EDIT : Como o debugfs não está habilitado no kernel, você pode tentar date >>/tmp/wtf && ps -eo "cmd,pid,min_flt,maj_flt" >>/tmp/wtf ou similar. Fazer o log de falhas de página não é, obviamente, o mesmo que usar o btrace, mas se você tiver sorte, pode dar uma pista sobre os processos que mais demandam disco. Eu apenas tentei que um dos meus servidores e lista mais intensivos de E / S incluísse os processos que eu sei que estão consumindo muita E / S.