☰

Analisando o tráfego de IO do disco

tag-icon • tag-icon ubuntu software-raid performance io
Analisando o tráfego de IO do disco

Estou executando um servidor web (Ubuntu 11.04) que apresenta alto tráfego de gravação inesperado. Quando o servidor não deve gravar, a quantidade de tráfego de gravação é comparável ao tráfego de leitura.

Preocupado com operações de gravação desnecessárias, tentei analisar o que estava errado no sistema. Posso excluir registros pesados ​​do Apache ou problemas de tempo de acesso (usandonoatimeconfiguração de montagem).

Para rastrear o problema, eu queria ver quais arquivos foram gravados. Portanto, habilitei o login IO via block_dump (entrada de blog útil sobre este tópico:roda dentada.io). Cada atividade do sistema de arquivos será registrada no syslog. Aqui está um pequeno trecho do meu sistema:

21 de agosto 18:22:55 kernel xxxxx: [3984721.590864] apache2 (2761): READ bloco 1098502400 em md2 (8 setores)
21 de agosto 18:22:55 kernel xxxxx: [3984721.594005] kjournald (316): bloco WRITE 2224394648 em md2 (8 setores)
21 de agosto 18:22:55 kernel xxxxx: [3984721.594029] md2_raid1 (260): bloco WRITE 2925532672 em sdb3 (8 setores)
21 de agosto 18:22:55 kernel xxxxx: [3984721.594044] md2_raid1 (260): WRITE bloco 2925532672 em sda3 (8 setores)
21 de agosto 18:22:55 kernel xxxxx: [3984721.644244] apache2 (2761): READ bloco 2242118744 em md2 (8 setores)

Ok, agora sei quais blocos foram escritos. Mas existe uma maneira de realmente identificar os nomes dos arquivos que foram escritos com base nesses IDs de bloco?

Obrigado pela ajuda!

BTW: Estou usando um Software Raid, pode ser parte do problema.

Responder1

Assumindo ext2/ext3/ext4, comece com

[406420.877412] vi(12496): READ block 4522288 on dm-1 (8 sectors)

Determine o tamanho do bloco do sistema de arquivos:

# /sbin/dumpe2fs /dev/dm-1 | grep 'Block size'
dumpe2fs 1.42.3 (14-May-2012)
Block size:               4096

Supondo que você tenha uma unidade com setores de 512 bytes, divida o bloco por 4096/512, ou seja, 8 para obter 565286.

Em debugfsuso, uma combinação de ichecke ncheck:

debugfs:  icheck 565286
Block   Inode number
565286  142506

debugfs:  ncheck 142506
Inode   Pathname
142506  /etc/security/time.conf

Editar: faça isso nos dispositivos md*, não nos dispositivos sd*. A E/S do dispositivo sd* é o resultado de invasão de software.

Responder2

O sistema de arquivos reside em um nível mais alto de abstração do que dispositivos de bloco e RAIDs de software. Dito isto, o RAID de software não faz parte do problema com 99,9% de probabilidade, é apenas um dispositivo de bloco. Portanto, você deve usar outro conjunto de ferramentas para analisar sua atividade de I/O. Eu recomendaria começar iotopidentificando primeiro o principal redator entre os processos em execução. Então você poderá usar lsofe straceidentificar em quais arquivos estão sendo gravados.

Responder3

Linux tem um sistema de kernel chamadonotificarpara observar quaisquer alterações em um arquivo. Na userland, pode-se usar oferramentas inotify( apt-get install inotify-tools) para monitorar um diretório. No entanto, cada arquivo deve ter um relógio individual colocado nele. Você pode aplicá-los recursivamente a um diretório (até mesmo à raiz), mas quanto menos você observar, menor será a sobrecarga.

Outras opções para restringir as coisas incluem:

  • atopo que permitirá que você veja quais processos estão executando gravações
  • auditctlque tem uma sintaxe muito misteriosa, mas permite que relógios sejam colocados em qualquer chamada de sistema

informação relacionada