Como resolver o servidor intermitente trava? Escreva para (e leia de) um disco para completamente

2

Temos um servidor LAMP por cerca de 6 meses. CentOS 7.0

Ele foi executado sem parar sem reiniciar pelos primeiros 3 meses e depois travar.

Em seguida, ele é executado pelos próximos 2 meses (também sem parar sem reiniciar) e depois travar novamente.

Em seguida, ele é executado durante 14 dias e depois é interrompido.

Em seguida, ele é executado durante 14 dias e depois é interrompido.

Após cada interrupção, tivemos que reiniciar o servidor. Nós não adicionamos / atualizamos nenhum software de sistema.

Os sintomas do travamento são os mesmos em todos esses casos:

Escreva para (e leia de) um disco pára completamente.

O servidor web e o banco de dados MySQL param de funcionar. Nós não podemos entrar através do console físico ou remotamente via ssh.

No entanto, quando este travamento aconteceu, tive sessões de shell ssh remotas abertas com comandos linux "top" e "mytop" em execução, e elas estavam funcionando (atualizando) até o servidor ser reiniciado.

Então isso prova que o servidor não estava congelado completamente. Alguns dos softwares ainda estavam em execução.

O servidor não conseguiu reiniciar normalmente.

Não encontrei nada nos logs. Todos os registros foram interrompidos ao mesmo tempo.

As últimas entradas no console físico (KVM) quando ocorre a interrupção estavam mencionando erros com o controlador Adaptec RAID. Por favor, veja abaixo:

00001
[1143965.194144) 0000000000000246 000000014423ecb4 1111880869b6b740 ffff880000c 00040
00040
[1143965.194786] Call Trace:
[1143965.195044] [<Ifffffffa007f46b>] aac_fib_send+0x3db/8x510 [aacraid] 
[1143965.195307] [<ffffffffa00794d8>] aac_get_adapter_info+0xc8/8xb70 [aacraid] [1143965.195573] [<ffffffffa007e990>] _aac_reset_adapter+0x430/0x620 [aacraid] 
[1143965.195573] [<ffffffffa007e990>] _aac_reset_adapter+0x430/0x620 [aacraid] 
[1143965.195838] [<ffffffffa0071a79>] aac_reset_adapter+0xa9/0x290 [aacraid] 
[1143965.196101] [<ffffffffa0076214>] aac_eh_reset+Oxla4/0xle0 [aacraid] 
[1143965.196368] [<ffffffff813d6d83>] scsi_try_host_reset+0x43/0x100 
[1143965.196628] [<ffffffff813d812,17>] scsi_eh_ready_devs+0x887/0xc20 
[1143965.196889] [<ffffffff813da43c>] scsi_error_handler+0x52c/8x820 
[1143965.197151] [<ffffffff813d9110>] ? scsi_eh_get_sense+0x2a0/0x2a0 
[1143965.197415] [<1111111181085aff>] kthread+0xcf/8xe0
[1143965.197675] [<1111111181085a30>] ? kthread_create_on_node+0x140/0x140 
[1143965.197939] [<111111118151316c>] ret_from_fork+Ox7c/OxbO
[1143965.198200] [<1111111181085a30>] ? kthread_create_on_node+0x140/0x140 
[1143965.198461] Code: 48 c? 87 b8 00 00 00 00 30 08 a0 5d c3 Al 11 84 00 00 00 00 00 Of 11 44 00 00 55 48 8b 87 90 01 00 00 48 89 e5 8b 80 be 00 00 00 <a8> 04 75 14 f6 c4 01 75 14 25 80 00 00 00 83 f8 01 19 c0 83 e0
00 00 Of 11 44 00 00 55 48 8b 87 90 01 00 00 48 89 e5 8b 80 be 00 00 00 <a8> 04 75 14 f6 c4 01 75 14 25 80 00 00 00 83 f8 01 19 c0 83 e0
75 14 f6 c4 01 75 14 25 80 00 00 00 83 f8 01 19 c0 83 e0
[1143974.082729] aacraid: aac_fib_send: first asynchronous command timed out. 
[1143974.082729] Usually a result of a PCI interrupt routing problem; 
[1143974.082729] update mother board BIOS or consider utilizing one of 
[1143974.082729] the SAFE mode kernel options (acpi, apic etc)

Substituímos a placa controladora RAID, mas ela não resolveu o problema, tivemos um servidor interrompido novamente com os mesmos sintomas.

Agora estou tendo um shell ssh remoto em execução o tempo todo com "dmesg -wH" esperando capturar mais do log dmesg quando travar acontecer novamente.

O servidor está tendo uma placa Adaptec RAID com dois SATA SSD 960GB no RAID 1 e dois SATA 500 GB HDD no RAID 1.

S.M.A.R.T. os atributos estão corretos para todas as unidades.

Algum conselho?

Editar # 1 9/13/2015:
Há muito espaço livre em todas as partições.
Os logs estão girando corretamente.

Editar # 2 9/13/2015:
Controlador RAID: Adaptec ASR71605
BIOS: 7.5-0 (32069)
Firmware: 7.5-0 (32069)
Driver: 1,2-0 (30300)
Boot Flash: 7.5-0 (32069)

    
por alxsr 13.09.2015 / 03:23

1 resposta

0

A solução foi usar o próprio driver Adaptec (ele pode ser baixado do site deles) e não o driver opensource que veio com o CentOS. O servidor foi executado por cerca de 11 meses com o driver Adaptec (em seguida, o servidor foi interrompido por motivo desconhecido), o que é uma grande melhoria em relação ao tempo de atividade de 14 dias com o driver de código aberto.

    
por 07.11.2016 / 01:08