Como descobrir qual processo está gravando regularmente no disco?

Question

Como posso encontrar qual processo está constantemente gravando no disco?

Eu gosto da minha estação de trabalho para ficar em silêncio e eu apenas construir um novo sistema (P8B75-M + Core i5 3450s - o 's' porque tem um menor TDP max) com fãs silenciosos etc. e instalado Debian Wheezy 64 bits.

E algo está me dando nos nervos: eu posso ouvir algum tipo de padrão como se o disco rígido estivesse escrevendo ou procurando algo ( tick ... tick ... tick ... trrrrrr enxague e repita a cada segundo ou mais).

No passado eu tive um problema semelhante no passado (muitos, muitos anos atrás) e acabou que era algum log do CUPS ou algo assim e eu simplesmente redirecionei aquele (não importante) logging para um disco RAM (real) .

Mas aqui não tenho certeza.

Eu tentei o seguinte:

ls -lR /var/log > /tmp/a.tmp && sleep 5 && ls -lR /var/log > /tmp/b.tmp && diff /tmp/?.tmp

mas nada está mudando lá.

Agora, o mais estranho é que também ouço o padrão quando o prompt que me pede para inserir minha frase secreta de decodificação do LVM está sendo mostrado.

Poderia ser algo no kernel / sistema que acabei de instalar ou tenho um disco rígido defeituoso?

hdparm -tT /dev/sda reporta uma velocidade HD correta (130 GB / s não armazenada em cache, sata 6 GB) e eu já instalei e compilou a partir de fontes grandes (Emacs) sem problemas, então não acho que o sistema seja ruim.

(HD é um Seagate Barracude 500GB)

    

Answer 1

Você tentou examinar quais programas como iotop está aparecendo? Ele informará exatamente que tipo de processo está sendo gravado no disco.

Exemplo de saída

:

Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
    1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % init
    2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
    3 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/0]
    6 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/0]
    7 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [watchdog/0]
    8 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/1]
 1033 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [flush-8:0]
   10 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/1]

    

Answer 2

Você pode ativar a depuração de E / S via echo 1 > /proc/sys/vm/block_dump e, em seguida, observar as mensagens de depuração em / var / log / syslog . Isso tem a vantagem de obter algum tipo de arquivo de log com atividades passadas, enquanto iotop apenas mostra a atividade atual.

    

Answer 3

Assumindo que os ruídos do disco são devidos a um processo que causa uma gravação e não a algum problema de spindown de disco , você pode usar o subsistema de auditoria (instale o auditd package ). Coloque um relógio nas chamadas sync e seus amigos:

auditctl -S sync -S fsync -S fdatasync -a exit,always

Assista os registros em /var/log/audit/audit.log . Tenha cuidado para não fazer isso se os logs de auditoria forem liberados! Verifique em /etc/auditd.conf se a opção flush está definida como none .

Se os arquivos estão sendo liberados com freqüência, um provável culpado é os logs do sistema. Por exemplo, se você registrar tentativas de conexão de entrada com falha e alguém estiver testando sua máquina, isso gerará muitas entradas; isso pode fazer com que um disco emita ruídos no estilo de metralhadoras. Com o daemon de log básico sysklogd, verifique /etc/syslog.conf : se um nome de arquivo de log não for precedido por - , esse log será liberado para o disco após cada gravação.

    

Answer 4

Pode ser que suas unidades sejam desativadas automaticamente, e muitas unidades de classe do consumidor fazem isso hoje em dia. Infelizmente, mesmo em um sistema levemente carregado, isso faz com que as unidades girem e girem novamente, especialmente se você estiver executando o hddtemp ou similar para monitorar a temperatura da unidade (a maioria das unidades não permite consultar o valor da temperatura SMART) sem girar o drive - cretino!).

Isso não é apenas incômodo, pode desgastar as unidades mais rapidamente, já que muitas unidades têm apenas um número limitado de ciclos de estacionamento. por exemplo. veja o link para obter uma descrição do problema.

Desabilito o spindown ocioso em todas as minhas unidades com o seguinte código shell. você poderia colocá-lo em um script /etc/rc.boot ou em /etc/rc.local ou similar.

for disk in /dev/sd? ; do
  /sbin/hdparm -q -S 0 "/dev/$disk"
done

    

Answer 5

Acabei de descobrir que s.m.a.r.t estava causando um disco USB externo para girar de novo e de novo no meu pi de framboesa. Embora o SMART seja geralmente uma coisa boa, decidi desativá-lo novamente e, desde então, parece que a atividade de disco indesejada parou

    

Answer 6

Caso você precise restringi-lo a um disco exato, use o seguinte:

execute lsblk e procure o número do dispositivo. No caso abaixo, é 9:126

NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda           8:0    0   7.3T  0 disk  
└─md126       9:126  0  13.8T  0 raid0 /mnt/InternalPhase
sdb           8:16   0   7.3T  0 disk  
└─md126       9:126  0  13.8T  0 raid0 /mnt/InternalPhase
sdc           8:32   0   7.3T  0 disk  
└─sdc1        8:33   0   7.3T  0 part  /mnt/InternalFBE

execute lsof | grep '9,126' com o : substitua por , em comparação com o número do disco acima. No meu caso, isso aparece como:

bash      389162            root  cwd       DIR              9,126      4096  449183796 /mnt/InternalPhase/0000000001/CHANNEL01/LIVE/PHASE/DATA/2018/10/04

com o PID de 389162 mata este processo usando:

kill -9 389162

    

Answer 7

Você pode adivinhar isso um pouco. Deve reduzi-lo para a maioria.

find / -mount -newer /proc -print

Forneça os arquivos modificados desde a inicialização no dispositivo físico do sistema / files. Conhecer os arquivos provavelmente ajudará a identificar o autor.

    

Answer 8

O problema é que o sistema precisa liberar dados dos buffers de disco para o disco sempre 5 segundos ou mais por padrão. Assim, se o disco girar, haverá pouca opção além de girar novamente quando precisar de um flush. Portanto, o problema não é realmente evitável, a não ser desativando os spins downs ou os recursos de gerenciamento de energia do disco por completo hdparm -B 255 /dev/hdax . Esta é provavelmente a melhor opção, uma vez que reiniciar muitas vezes pode definitivamente ser mais prejudicial do que simplesmente ficar ligado o tempo todo.