[MASOCH-L] servidor travando sem motivo aparente

Rafael Possamai rafaelpossa at gmail.com
Fri Mar 30 20:05:09 -03 2007


Olá Fernando,

    Na realidade achei muito interessante os testes, não tinha pensado 
nisso. Eu executei o teste de cópias de arquivos (aquele de 1gb) até a cópia 
5 e não houve diferenças(o diff não mostrou nada) e agora estou executando o 
teste do md5sum junto com o do badblocks pra estressar o CPU e o HD como 
indicaste e o server está forte até agora.
    Eu verifiquei tudo que o pessoal andou comentando também e creio que 
desabilitar o USB controller na BIOS possa trazer um bom resultado. A última 
coisa que espero fazer é recompilar o kernel.

OBS.: nesta segunda instalação além de mudar pra kernel 2.6 e para ReiserFS 
eu utilizei o debian net-install e ele está bem seco(300mb), não deixei o 
base-config instalar aqueles pacotes por padrão e desativei no rcx.d todos 
os serviços desnecessários. não sei se é por isso que ele tem se mostrado 
mais estável agora, espero que tenha sido por causa das modificações na bios 
e na troca de um pente de memória, menos pior.

Grato,
Rafael Possamai



----- Original Message ----- 
From: "Fernando Ulisses dos Santos" <fernando at bluesolutions.com.br>
To: "Mail Aid and Succor, On-line Comfort and Help" 
<masoch-l at eng.registro.br>
Sent: Friday, March 30, 2007 6:09 PM
Subject: Re: [MASOCH-L] servidor travando sem motivo aparente


Rafael,

Pela descrição que você está dando, funcionava, começou a travar depois de
2 anos rodando, pode ser realmente desgaste do hardware.

Você está medindo temperatura de processador, temperatura de placa mãe,
saída das voltagens da fonte? A máquina é montada ou é de grife?

Você disse que estressou a memória com o memtest, mas tentou estressar CPU
e HD? Não, tente então:

md5sum /dev/zero  # execute esse comando para a quantidade de
processadores que tiver, deixe rodar de 10 min a 30 min

badblocks -sv /dev/hda # ou /dev/sda, etc, dependendo da sua instalação,
rode 1 para cada HD, tudo de uma vez

Esses dois comandos podem ser feitos com o servidor rodando (claro, irão
prejudicar na performance). É interessante, inclusive, rodar tudo junto,
pra estressar de verdade.

Acompanhe a temperatura do CPU enquanto roda o md5sum, veja se ele não
apresenta o problema quando chegar em uma determinada temperatura. Para
acompanhar a temperatura, use o comando sensors do pacote lm_sensors.

O badblocks varre o HD em busca de badblock, é interessante nesse caso por
causar grande trasnferência de dados.

Verifique a temperatura do HD durante o teste usando o comando smartctl do
pacote smarttools. A maioria dos HDs foi projetada para trabalhar até 50
graus no máximo. De qualquer forma, o HD ajuda a aquecer o interior do
gabinete, e pode comprometer outras peças.

No teste badblocks ele não testa a integridade na transferência de dados.
Um teste legal seria criar um arquivo grande, copiar ele várias vezes e
comparar no final, isso testa HD, CPU, DMA, memória, etc, pode usar:

dd if=/dev/zero of=0 bs=1024 count=1024000 # vai gerar arquivo de 1Gb
chamado 0
cp 0 1
cp 1 2
cp 2 3
cp 3 4
cp 4 5
diff 5 1

Não pode haver diferenças entre o último e o primeiro arquivo.

Se conseguir travar, algumas considerações:
- em máquinas montadas, as fontes usadas que são de "450W", não atingem
esse desempenho e com passar do tempo perdem a eficiência, pode testar
trocar a fonte por uma convencional para ver se resolve o problema,
resolvendo, compre uma fonte profissional, exemplo: Seventeam 350W
- coolers, mesmo rodando, podem perder eficiência com o passar do tempo,
se a temperatura subiu muito no teste do md5sum, considere trocar
- pasta térmica no processador (em máquinas montadas), mesma consideração
do cooler
- em máquinas montadas, alguns fabricantes de placas mãe de baixo custo
estão deixando de incluir dissipador no Chipset, na revista PC&CIA de uns
2 meses atrás eles relataram um que chegava a mais de 100 graus, e sugerem
instalar dissipadores quando vier sem.

É isso, espero que ajude.

--
Fernando Ulisses dos Santos
Blue Solutions - Soluções em TI
19-3551-3898 / 11-4062-9218
fernando at bluesolutions.com.br
Certificado Linux LPIC-1

Rafael Possamai escreveu:
> opa, agradeço pela ajuda.
> bom, você fala de um gcc nativo no kernel?
> o que eu achei estranho é que de ontém para hoje deixei o sistema
> rodando(ocioso é claro) e ele não apresentou nenhum problema. agora pouco
> atualizei o kernel pelo apt (não por isto, mas por que estava aparecendo
> na
> lista de upgrades) e até agora nenhum erro ainda. ah, como indicaram, no
> último reboot eu desabilitei o USB Controller na CMOS. bom, vou verificar
> tudo que o pessoal falou e se não tiver jeito mesmo provavelmente é o
> problema de "junta...".
>
> abraço,
> rafael possamai
>
>
>
>
> ----- Original Message -----
> From: "Jorge Luiz Correa" <jorge at acmesecurity.org>
> To: "Mail Aid and Succor, On-line Comfort and Help"
> <masoch-l at eng.registro.br>
> Sent: Friday, March 30, 2007 11:43 AM
> Subject: Re: [MASOCH-L] servidor travando sem motivo aparente
>
>
> Na Internet há diversos depoimentos de pessoas com 'crashes' deste tipo,
> utilizando o mesmo sistema. Parece que na maioria, o problema está em
> configurações de otimização do arquivo make.conf ou versões antigas do
> GCC. Como solução (em diversos forums), aconselha-se trocar o GCC para
> uma versão mais nova e recompilar o kernel. Você pode gerar um kernel
> otimizado para o servidor. E como é Debian, pode gerar pacote :P
>
> http://www.dicas-l.com.br/dicas-l/20031121.php
>
> Ainda, dependendo do hardware utilizado (principalmente se for antigo) o
> kernel 2.6 parece não combinar muito bem, não mantendo o suporte a
> alguns dispositivos.
>
> Abraços!
> :)
>
> Rafael Possamai wrote:
>> olá pessoal,
>>
>>     tenho uma máquina que começou a dar problemas nestes últimos dias,
>> estou rodando debian nela e houve vários 'kernel panic' sem motivo
>> aparente para mim. já troquei o HD, tirei um dos pentes de memória e fiz
>> um memtest de mais ou menos 24horas. nenhuma das alternativas funcionou,
>> creio que interpretando os códigos que aparecem no erro seja mais fácil
>> descobrir, porém neste casso os mesmos parecem grego pra mim, hehe.
>>     alguém poderia dar uma força? gravei dois kernel panic que
>> aconteceram
>> recentemente:
>> http://www.ext3.com.br/server/kernelpanic.jpg
>> http://www.ext3.com.br/server/kernelpanic2.jpg (agora pouco)
>>
>>
>> grato,
>> rafael possamai
>> __
>> masoch-l list
>> https://eng.registro.br/mailman/listinfo/masoch-l
>>
>
>
> --
> jorge (shift+2) acmesecurity . org
> ACME! - Advanced Counter-Measures Environment
> Computer Security Research - Unesp
>
>
>
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
>
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
>


__
masoch-l list
https://eng.registro.br/mailman/listinfo/masoch-l 




More information about the masoch-l mailing list