Qual processo está usando todo o meu disco IO

120

Se eu usar "top", posso ver qual CPU está ocupada e qual processo está usando toda a minha CPU.

Se eu usar "iostat -x", posso ver qual unidade está ocupada.

Mas como posso ver qual processo está usando toda a taxa de transferência da unidade?

— Matthew Crumley
fonte

2

Bem, tecnicamente isso também é verdade para o Linux, já que os processos do usuário apenas modificam as páginas no cache de página ...;)

— Damon

Apenas a pergunta que eu tinha e a resposta que estava procurando, mas esse tipo de pergunta não se encaixa melhor no SuperUser?

— Zeta Two

E é por isso que o Linux é inferior ao Solaris e MacOS, porque eles têm o dtrace integrado que torna isso trivialmente simples de descobrir: - /

— Thorbjørn Ravn Andersen

162

Você está procurando iotop(supondo que você tenha kernel> 2.6.20 e Python 2.5). Caso contrário, você está tentando se conectar ao sistema de arquivos. Eu recomendo o primeiro.

— phresus
fonte

8

iotopparece estar mostrando a largura de banda de E / S em vez do número de IOPS consumidos pelos processos. Isso não é super relevante. Um processo que faz muitas pequenas gravações + sincronização vai consumir mais da capacidade de E / S do disco do que um processo que grava um grande lote contíguo de dados em alta velocidade.

— Arnaud Le Blanc

Para pequenas gravações, tudo que vi foi [jdb2/nvme0n1p1]no iotop, mas tive sorte em habilitar / proc / sys / vm / block_dump e comparar a saída com um sistema saudável / estável lxadm.com/Simple_filesystem_read/write_tracing_with_/proc/sys/… Isso ajudou a encontrar um contêiner do docker que gerava continuamente solicitações kubectl, esgotando os créditos de burst de um volume EBS com entradas /home/spinnaker/.kube/cache/discovery/.../serverresources.json. Depois de restringir as coisas a um nome de usuário / processo, algo como iotop -atku systemd-network | grep kubectltambém pode ajudar

— Greg Bray

16

Para descobrir quais processos no estado 'D' (aguardando resposta do disco) estão em execução:

while true; do date; ps aux | awk '{if($8=="D") print $0;}'; sleep 1; done

ou

watch -n1 -d "ps axu | awk '{if (\$8==\"D\") {print \$0}}'"

Wed Aug 29 13:00:46 CLT 2012
root       321  0.0  0.0      0     0 ?        D    May28   4:25  \_ [jbd2/dm-0-8]
Wed Aug 29 13:00:47 CLT 2012
Wed Aug 29 13:00:48 CLT 2012
Wed Aug 29 13:00:49 CLT 2012
Wed Aug 29 13:00:50 CLT 2012
root       321  0.0  0.0      0     0 ?        D    May28   4:25  \_ [jbd2/dm-0-8]
Wed Aug 29 13:00:51 CLT 2012
Wed Aug 29 13:00:52 CLT 2012
Wed Aug 29 13:00:53 CLT 2012
Wed Aug 29 13:00:55 CLT 2012
Wed Aug 29 13:00:56 CLT 2012
root       321  0.0  0.0      0     0 ?        D    May28   4:25  \_ [jbd2/dm-0-8]
Wed Aug 29 13:00:57 CLT 2012
root       302  0.0  0.0      0     0 ?        D    May28   3:07  \_ [kdmflush]
root       321  0.0  0.0      0     0 ?        D    May28   4:25  \_ [jbd2/dm-0-8]
Wed Aug 29 13:00:58 CLT 2012
root       302  0.0  0.0      0     0 ?        D    May28   3:07  \_ [kdmflush]
root       321  0.0  0.0      0     0 ?        D    May28   4:25  \_ [jbd2/dm-0-8]
Wed Aug 29 13:00:59 CLT 2012
root       302  0.0  0.0      0     0 ?        D    May28   3:07  \_ [kdmflush]
root       321  0.0  0.0      0     0 ?        D    May28   4:25  \_ [jbd2/dm-0-8]
Wed Aug 29 13:01:00 CLT 2012
root       302  0.0  0.0      0     0 ?        D    May28   3:07  \_ [kdmflush]
root       321  0.0  0.0      0     0 ?        D    May28   4:25  \_ [jbd2/dm-0-8]
Wed Aug 29 13:01:01 CLT 2012
root       302  0.0  0.0      0     0 ?        D    May28   3:07  \_ [kdmflush]
root       321  0.0  0.0      0     0 ?        D    May28   4:25  \_ [jbd2/dm-0-8]
Wed Aug 29 13:01:02 CLT 2012
Wed Aug 29 13:01:03 CLT 2012
root       321  0.0  0.0      0     0 ?        D    May28   4:25  \_ [jbd2/dm-0-8]

Como você pode ver no resultado, o jdb2 / dm-0-8 (processo de registro ext4) e o kdmflush bloqueiam constantemente o Linux.

Para mais detalhes, este URL pode ser útil: Linux Wait-IO Problem

— Quentinxue
fonte

11

atop também funciona bem e instala facilmente até mesmo em sistemas CentOS 5.x mais antigos que não podem ser executados no iotop. Clique dpara mostrar os detalhes do disco, ?para obter ajuda.

ATOP - mybox                           2014/09/08  15:26:00                           ------                            10s elapsed
PRC |  sys    0.33s |  user   1.08s |                | #proc    161  |  #zombie    0 |  clones    31 |                | #exit         16  |
CPU |  sys   4% |  user     11% |  irq       0%  | idle    306%  |  wait     79% |               |  steal     1%  | guest     0%  |
cpu |  sys   2% |  user      8% |  irq       0%  | idle     11%  |  cpu000 w 78% |               |  steal     0%  | guest     0%  |
cpu |  sys   1% |  user      1% |  irq       0%  | idle     98%  |  cpu001 w  0% |               |  steal     0%  | guest     0%  |
cpu |  sys   1% |  user      1% |  irq       0%  | idle     99%  |  cpu003 w  0% |               |  steal     0%  | guest     0%  |
cpu |  sys   0% |  user      1% |  irq       0%  | idle     99%  |  cpu002 w  0% |               |  steal     0%  | guest     0%  |
CPL |  avg1    2.09 |  avg5    2.09 |  avg15   2.09  |               |  csw    54184 |  intr   33581 |                | numcpu     4  |
MEM |  tot     8.0G |  free   81.9M |  cache   2.9G  | dirty   0.8M  |  buff  174.7M |  slab  305.0M |                |               |
SWP |  tot     2.0G |  free    2.0G |                |               |               |               |  vmcom   8.4G  | vmlim   6.0G  |
LVM |  Group00-root |  busy     85% |  read       0  | write  30658  |  KiB/w      4 |  MBr/s   0.00 |  MBw/s  11.98  | avio 0.28 ms  |
DSK |          xvdb |  busy     85% |  read       0  | write  23706  |  KiB/w      5 |  MBr/s   0.00 |  MBw/s  11.97  | avio 0.36 ms  |
NET |  transport    |  tcpi    2705 |  tcpo    2008  | udpi      36  |  udpo      43 |  tcpao     14 |  tcppo     45  | tcprs      1  |
NET |  network      |  ipi     2788 |  ipo     2072  | ipfrw      0  |  deliv   2768 |               |  icmpi      7  | icmpo     20  |
NET |  eth0    ---- |  pcki    2344 |  pcko    1623  | si 1455 Kbps  |  so  781 Kbps |  erri       0 |  erro       0  | drpo       0  |
NET |  lo      ---- |  pcki     423 |  pcko     423  | si   88 Kbps  |  so   88 Kbps |  erri           0 |  erro       0  | drpo       0  |
NET |  eth1    ---- |  pcki  22 |  pcko      26  | si    3 Kbps  |  so    5 Kbps |  erri       0 |  erro       0  | drpo       0  |

  PID                   RDDSK                    WRDSK                   WCANCL                    DSK                   CMD        1/1
 9862                      0K                   53124K                       0K                    98%                   java
  358                      0K                     636K                       0K                     1%                   jbd2/dm-0-8
13893                      0K                     192K                      72K                     0%                   java
 1699                      0K                      60K                       0K                     0%                   syslogd
 4668                      0K                      24K                       0K                     0%                   zabbix_agentd

Isso mostra claramente que java pid 9862 é o culpado.

— Steve Kehlet
fonte

4

TL; DR

Se você pode usar iotop, faça-o. Caso contrário, isso pode ajudar.

Use e top, em seguida, use estes atalhos:

d 1 = set refresh time from 3 to 1 second

1   = show stats for each cpu, not cumulated

Isso deve mostrar valores > 1.0 wapara pelo menos um núcleo - se não houver espera de disco, simplesmente não há carga de E / S e não há necessidade de procurar mais. Cargas significativas geralmente começam > 15.0 wa.

x       = highlight current sort column 
< and > = change sort column
R       = reverse sort order

Escolha 'S', a coluna de status do processo. Inverta a ordem de classificação para que os processos 'R' (em execução) sejam exibidos na parte superior. Se você puder localizar processos 'D' (esperando pelo disco), terá um indicador de qual pode ser o culpado.

— sjas
fonte

3

Para usuários do KDE, você pode usar 'ctrl-esc' para chamar um monitor de atividade do sistema e há gráficos de atividades de E / S com a id e o nome do processo.

Não tenho permissão para fazer upload de imagem, devido ao 'novo status de usuário', mas você pode conferir a imagem abaixo. Possui uma coluna para leitura e gravação de IO.

— Patrick
fonte

2

Você já considerou lsof(listar arquivos abertos)?

— Apolinsky
fonte

3

que mostra apenas identificadores de arquivo abertos, não MB / s para cada arquivo. iotop faz isso.

— oligofren

2

iotop com a bandeira -a:

-a, --accumulated     show accumulated I/O instead of bandwidth

— Chris Godwin
fonte