Vendo o Log do Kernel
Antes de tudo é bom sabermos como acessar os logs do kernel. Há diversas maneiras e pode ser ligeiramente diferente a depender da distro linux sendo usada.
Uma das maneiras mais comuns é através do arquivo /var/log/kern.log ou por meio do comando “dmesg“. Podemos usar a combinação abaixo para vermos os logs em tempo real:
- tail -f /var/log/kern.log
- dmesg -w
A Mensagem “interrupt took too long”
Traduzindo, “interrupt took too long” quer dizer “Interrupção demorou muito”.
Uma interrupção ocorre quando um programa ou dispositivo(HD, teclado, mouse etc.) quer usar o processador. É enviado um pedido(IRQ) para que o processador pare o que está fazendo e atenda a quem enviou a solicitação de interrupção(IRQ).
Ao acessar o log do kernel podemos nos deparar com a seguinte mensagem: “interrupt took too long“.
kernel: [ 6491.061361] perf: interrupt took too long (6650 > 6452), lowering kernel.perf_event_max_sample_rate to 30000
Essa mensagem não se trata de um erro, é apenas um aviso indicando que interrupção(interrupt) levou muito tempo.
Não se preocupe! Não é um erro.
O que Causa essa Demora?
Essa demora na interrupção pode ser causado por muitas razões. Podemos citar:
- Interrupção de I/O(entrada/saída) de Disco: Leitura e escrita em disco lento, falho ou sobrecarregado pode fazer um interrupt demorar mais que o normal.
- Problemas e Raid ou em Disco Danificado: novamente discos. Podemos ter um conjunto de discos trabalhando em raid ou um disco sozinho mais danificado.
- Interrupt I/O de Rede: Problemas com driver de rede pode causa demora em interrupções.
Identificando e Solucionando
Podemos identificar se o causador de uma interrupção longa é um disco simplesmente usando ferramentas de monitoramento de escrita e leitura de discos, como o iostat.
Se a causa não for leituras ou escritas em disco provavelmente será a rede. para identificar teremos que checar a rede e as informações no kernel linux.
Primeiramente devemos olhar se o problema é em algum drive de rede. Verifique os logs em /var/log/kern.log e também usar dmesg. Se esses arquivos de logs mostrarem problemas em vmxnet então você matará a charada ao identificar a rede como vilã.
Se não encontrar problema no kernel então provavelmente o adaptador de rede, a peça física de rede, será o problema.
Fontes: categoriaoutros, aerospike
Elder Rodrigues
Leitor voraz e um dos administradores do GNU/Linux Brasil no Whatsapp, facebook, youtube e nesse dito site: www.gnulinuxbrasil.com.br