Analisando o tráfego de E / S de disco

Question

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

Preocupado com a operação de gravação desnecessária, tentei analisar o que está errado no sistema. Posso excluir problemas pesados de registro em log do apache ou de tempo de acesso (usando a configuração de montagem noatime ).

Para rastrear o problema, eu queria ver quais arquivos foram gravados. Portanto, ativei o loggin de IO via block_dump (entrada de blog útil sobre este tópico: sprocket.io ). Toda atividade do sistema de arquivos será registrada no syslog. Aqui um trecho curto do meu sistema:

Aug 21 18:22:55 xxxxx kernel: [3984721.590864] apache2(2761): READ block 1098502400 on md2 (8 sectors)
Aug 21 18:22:55 xxxxx kernel: [3984721.594005] kjournald(316): WRITE block 2224394648 on md2 (8 sectors)
Aug 21 18:22:55 xxxxx kernel: [3984721.594029] md2_raid1(260): WRITE block 2925532672 on sdb3 (8 sectors)
Aug 21 18:22:55 xxxxx kernel: [3984721.594044] md2_raid1(260): WRITE block 2925532672 on sda3 (8 sectors)
Aug 21 18:22:55 xxxxx kernel: [3984721.644244] apache2(2761): READ block 2242118744 on md2 (8 sectors)

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

Obrigado pela sua ajuda!

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

    

Answer 1

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 debugfs use uma combinação de icheck e 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.

    

Answer 2

O sistema de arquivos reside em um nível mais alto de abstração do que os dispositivos de bloco e os RAIDs de software. Dito isto, o software RAID não é uma 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 E / S. Eu recomendaria começar com iotop para identificar primeiro o gravador principal entre os processos em execução. Em seguida, você poderá usar lsof e strace para identificar quais arquivos estão sendo gravados.

    

Answer 3

O Linux tem um sistema de kernel chamado inotify para assistir a qualquer alteração em um arquivo. No userland, pode-se usar as inotify-tools ( apt-get install inotify-tools ) para assistir a um diretório. Cada arquivo tem que ter um relógio individual colocado nele, no entanto. Você pode aplicá-las recursivamente a um diretório (até mesmo a raiz), mas quanto menos você observar, menos sobrecarga haverá.

Outras opções para restringir as coisas incluem:

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