[prnethost]

Olá... um dos meus servidores em Dallas agora +/- 3 a 4 dias para cá todo o santo dia, tem travado... e não faço a minima ideia do pq, pois nada é achado de spam, ou hacking nos logs.
Da ultima vez que o mesmo travou no putty ainda consegui ver que estava passando o comando repquota e estava consumindo 100% do cpu e foi a partir desse instante que ele começou a aumentar o load até deixar de responder.

Mas nos outros casos não aconteceu isso... simplesmente o servidor está com load normal... e primeiro deixa de ler e-mail, e passado x minutos deixa de abrir os sites.


Alguém poderia dar uma dica para resolver isso? Poderá ser problema de hardware?


Grato.

[juser]

As vezes contratar um gerenciamento particular faz tao bem a saúde ............................

[riopardo]

{... contratar um gerenciamento ... }

Eta frase chata........
Se sabe ajuda, senão não posta nada...........

[juser]

Qualquer opiniao deve ser válida até as "chatas"

[prnethost]

Valeu pela dica... mas o servidor já tem gerenciamento por terceiro e eles nada resolveram... não sabem o que é, pois dizem que nada acham nos logs.
Por isso, vim aqui por este meio solicitar vossa ajuda... pois por vezes a solução pode estar em outro local e por vezes bem mais simples.
E o gerenciamento parece estar complicando as coisas...

[riopardo]

.

This post has been edited by riopardo: 13 agosto 2009 - 06:00

[juser]

A sim, desculpe.

[little_oak]

Faz uma análise de disco e uso de memória.
No disco olha se há badblocks/clusters ou smart indo para o saco.
Em último caso (já conteceu comigo) a interface de rede pode estar morrendo (motivo de quedas de rede, mas nÃo justifica load muito alto).

[Gustavo G]

Algumas verificações importantes:

dmesg | grep -i err

Irá verificar erros recentes, problemas de RAM, aplicativos gerando qualquer log de erro significativo pro sistema operacional

tail -f -n XXXXX /var/log/messages

Similar ao anterior. XXX é o numero de linhas para trás. Sempre que o servidor travar, procure as ultimas entradas neste arquivo antes do travamento.

hdparm -Tt /dev/sda (sda, sdb, md0... seja qual for seu disco)

Te dá um relatório de leitura e escrita pro seu disco.

Os valores mínimos aceitáveis são:
Timing cached reads superior a 700
Timing buffered disk reads superior a 25

Se estiver inferior, é grande chance de problema no disco.

Faz um "top" e acompanha o parametro "wa" ou "iowait".

Este parametro é o quanto seu sistema operacional espera por leitura/escrita do disco. Se durante 5 minutos esse parametro se mantiver muito alto (a cima de uns 60-70%), pode indicar sobrecarga do servidor e/ou problema no disco.

Servidor travou. Será que é Firewall?

Não é dificil acontecer. As vezes o firewall pode estar em um nível de segurança muito alto (acontece muito com o CSF), e o servidor barra todo o tráfego sainte. Tente desativar o Firewall por alguns dias. Não é nada bom ficar sem firewall, mas ir por eliminação nunca faz mal. O APF é uma boa alternativa de firewall pra Linux.

Se usar o CSF, nunca esqueça de sempre fazer update nele.

Alugue um KVM remoto

Outra dica nossa, seria pedir a instalação de um KVM remoto. Desta forma você consegue verificar de forma segura a temperatura do processador, gabinete e outros parametros. Quando o servidor travar, você terá acesso total a máquina e poderá investigar uma possível mensagem de erro no sistema (se houver).


É basicamente isso.. Existem muitas variáveis. Principalmente quando muitos clientes rodam aplicações que desconhecemos.

Qualquer coisa pode mandar msn privada. Boa sorte.

This post has been edited by Gustavo G: 13 agosto 2009 - 08:21

[prnethost]

Olá... fiz os testes mencionados e eis os resultados:

root@server [~]# dmesg | grep -i err
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
CPU0: Intel® Xeon® CPU X3220 @ 2.40GHz<7>spurious 8259A interrupt: IRQ7.
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.DEV1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.DEV3._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP5._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP6._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIB._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 10 11 14 15) *7
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 10 11 14 15) *5
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 10 *11 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 *10 11 14 15)
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 169
ACPI: PCI Interrupt 0000:00:03.0[A] -> GSI 16 (level, low) -> IRQ 169
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 17 (level, low) -> IRQ 177
ACPI: PCI Interrupt 0000:00:1c.4[A] -> GSI 17 (level, low) -> IRQ 177
ACPI: PCI Interrupt 0000:00:1c.5[B] -> GSI 16 (level, low) -> IRQ 169
assign_interrupt_mode Found MSI capability
assign_interrupt_mode Found MSI capability
assign_interrupt_mode Found MSI capability
assign_interrupt_mode Found MSI capability
assign_interrupt_mode Found MSI capability
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 233
ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 50
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 50
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 58
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 233
ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 16 (level, low) -> IRQ 169
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 58
ACPI: PCI Interrupt 0000:0d:00.0[A] -> GSI 16 (level, low) -> IRQ 169
ACPI: PCI Interrupt 0000:0e:00.0[A] -> GSI 17 (level, low) -> IRQ 177
ACPI: PCI Interrupt 0000:00:1f.3[B] -> GSI 19 (level, low) -> IRQ 58
root@server [~]#




root@server [/]# hdparm -Tt /dev/sda7

/dev/sda7:
Timing cached reads: 13208 MB in 2.00 seconds = 6611.02 MB/sec
Timing buffered disk reads: 118 MB in 3.07 seconds = 38.41 MB/sec
root@server [/]#
root@server [/]#
root@server [/]#
root@server [/]# hdparm -Tt /dev/sdb1

/dev/sdb1:
Timing cached reads: 12464 MB in 2.00 seconds = 6239.30 MB/sec
Timing buffered disk reads: 186 MB in 3.00 seconds = 61.91 MB/sec
root@server [/]#

root@server [/]#

[Gustavo G]

Parecemo normais. Investigue com calma.

Rode apenas o "dmesg" , sem nenhum parametro.

Faça os outros testes.

[prnethost]

Olá, rodei o dmesg e apareceu uma série de mensagens que nem cabe tudo na janela do putty.
Mas as mensagens parecem ser normais...

Há possibilidade de ser de hardware?

[darkstarlinux]

Faz assim, usa o dmesg + o grep + more junto, joga tudo para dentro de um arquivo texto, ai posta o conteudo para analizarmos.

Att
Joabes

This post has been edited by darkstarlinux: 13 agosto 2009 - 11:54

[prnethost]

Olá pessoal, já estou chegando a algum lado... vejam isso:

root@server [~]# cd /home/
root@server [/home]# touch a
touch: cannot touch `a': Read-only file system
root@server [/home]#


Porque a partição /home fica em só leitura... como faço para ele ficar leitura/escrita?

Isso acontece passado x horas fica simplesmente assim... alguma solução?

[ergti]

Eu prefiro ter uma despesa ou investimento de tempo para trocar de estrutura ao invés de ficar relutando contra: a minha ignorância num determinado assunto: a resistência de um fornecedor em lidar com a ignorância dele e de muitos ao seu redor; correr risco de perder dados.

Os efeitos estão apontando alertas enviados pelo servidor, e há momentos em que certos tipos de operações não nos permitem muito tempo pra analisar a melhor opção, tem que agir antes que algo verdadeiramente ruim e irreversível, ocorra.

Daqui a pouco lhe darão um comando aqui que será fatal dada gravidade da coisa.

This post has been edited by ergti: 14 agosto 2009 - 01:22