O que procurar nos arquivos de log se eu achar que uma memória limitada ou espaço em disco está causando uma falha

Question

Solução de problemas de arquivos / var / log para uma série recente de falhas, o que devo procurar nos arquivos se eu acreditar que pouca memória ou espaço em disco são responsáveis? Existe um termo geral usado na linguagem de arremesso de erro do Linux para falhas de hardware desse tipo? E quais processos do sistema seriam afetados, como o kernel, por uma escassez crítica de memória?

Apenas como pano de fundo, eu estava trabalhando em um site do Drupal hospedado no laptop do meu projeto sandbox do Fedora 17 quando sofri essas falhas no sistema. Recentemente, baixei alguns arquivos bastante grandes (desde então, mudei para a mídia) e fiquei com cerca de 1,8G de espaço HD.

Encontrei algumas postagens úteis aqui sobre como monitorar o uso de memória com top ou o disco atual uso com du . Esta questão, no entanto, é especificamente sobre arquivos de log. Eu encontrei um post similar no Fedora Forums procurando por uma explicação de FPrintObject que liderou eu fazer o Memtest, mas nada é mal informado lá.

    

Answer 1

As informações que você está procurando não são encontradas nos registros normais do syslog. Para visualizar o histórico de desempenho a partir da linha de comando, o sysstat é uma excelente ferramenta.

Com o sysstat, o sadc coleta informações do sistema e as grava em um arquivo de log. O arquivo de log é um formato binário, mas pode ser visualizado com o comando sar .

Aqui está um exemplo de saída sar sem opções:

$ sar
09:15:01 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
10:05:01 AM     all     77.49      0.37     22.13      0.00      0.00      0.00
10:15:01 AM     all     77.30      0.40     22.29      0.00      0.00      0.00
10:25:01 AM     all     77.19      0.38     22.42      0.00      0.00      0.00
10:35:01 AM     all     39.31      0.35     23.80      0.01      0.00     36.53
10:45:01 AM     all     32.22      0.34     24.26      0.03      0.00     43.15
10:55:01 AM     all     32.80      0.33     23.78      0.01      0.00     43.08
11:05:01 AM     all     32.70      0.33     23.76      0.00      0.00     43.20
Average:        all     63.90      0.39     22.79      0.00      0.00     12.91

As informações que você vê são as mesmas informações fornecidas por top , mas são dados históricos. Você também pode ver informações detalhadas sobre RAM, rede e utilização de disco. Aqui está um exemplo para o uso da RAM:

$ sar -r
09:15:01 AM kbmemfree kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit
02:15:01 PM    457076   1357116     74.81    277876    810948    205520      5.40
02:25:01 PM    456836   1357356     74.82    277876    811168    205384      5.40
02:35:01 PM    456976   1357216     74.81    277876    811256    204728      5.38
02:45:01 PM    457036   1357156     74.81    277876    811368    204840      5.38
02:55:01 PM    456588   1357604     74.83    277896    811492    204924      5.38
Average:       332452   1481740     81.67    277720    793953    416953     10.96

Fora da execução do sar localmente, existem muitos sistemas de monitoramento que exibem dados de tendências de desempenho. Munin, cactos e zabbix são alguns exemplos. Eles têm o benefício de criar gráficos e manter os dados de vários servidores em um local centralizado.

Atualize para responder a partir de comentários:

O comando sar dirá se você ficou sem memória RAM antes da falha. Isso será óbvio, já que os kbbuffers e o kbcached vão cair drasticamente. Você também pode verificar o dmesg para o killer do OOM (out of memory), mas o dmesg só é gravado nos logs se o klogd estiver instalado. Você não verá nenhum logout em falta de espaço em disco, a menos que um aplicativo relate especificamente sua falha ao gravar no disco. No entanto, se o disco estiver cheio, o syslog não poderá gravar o log no disco.