Madame, você consegue mandar um dmesg?
As vezes esse I/O com erro aí pode estar escondendo disco falhando de verdade :).
Tive 3 hds esse ano de 1 tb cada um que foram direto para o inferno em detrimento disto. (Não Scsi)Em 30 de novembro de 2014 20:18, Rodrigo Cunha <rodrigo.root.rj@gmail.com> escreveu:Dugida,o que seria uma aplicaçao monster.Nao sei o que é esta aplicação.
Em domingo, 30 de novembro de 2014, Rodrigo Cunha <rodrigo.root.rj@gmail.com> escreveu:
> Bom, posso te dar uma dica generica de compilação. Utilize kernels com o segundo caractere par. Tipo 2.4 ao invés de 2.5, por padrão os ímpares são atualizações não estaveis.Outra dica é compilar na mão.ao inves de um upgrade pelo yum, embora seja um procedimento penoso você pode criar varios kernels com varios modulos carregados ou se for o caso compilar um kernel novo com o set up do antetior.
> Daí vai carregando os kernels como tentativa e erro.
> Logico que o procedimento nao se aplica a servidores em produção, mas este for o caso aconselho a utilizacao de um pool de servidores paralelos para atualização da S/O
>
> Em quarta-feira, 26 de novembro de 2014, Sarah Milani <sarah.milani@gmail.com> escreveu:
>> Então gente, o que roda nesse server é uma aplicação "monster" em jboss. Não tenho acesso aos logs da aplicação. =/
>> Mas, partindo do principio que este evento ocorre quando o numero de escrita/leitura em disco aumenta ao ponto de provocar o travamento,..provavelmente, algum módulo adicional da aplicação tá requisitando isso.
>> Perdi de ver o log no host (vmware) que hospeda o servidor, pois com o rotate...só tem log de hoje =/
>>
>> Enfim, vou monitorar e no próximo caso de travamento, ver se consigo pegar o log disso, na camada VMware.
>>
>> Desde já agradeço, pela atenção.
>> ;)
>>
>>
>> Em 26 de novembro de 2014 15:32, Cleiton Alves <cleitondebian@gmail.com> escreveu:
>>>
>>> Sara
>>> Que tipo de aplicaçao roda nesse servidor ? se der poste os logs para gente dar uma mitigada no ocorrido ok
>>> Abs
>>> Em 26 de novembro de 2014 08:55, Silva, Lawton Bonnevialle Gomes da <lawton.silva@unify.com> escreveu:
>>>>
>>>> Bom dia Sarah;
>>>>
>>>> Verifique também no log de servidor storage, caso seja remoto, caso seja local veja o /var/log/messages
>>>>
>>>>
>>>> On Wed, 2014-11-26 at 07:30 -0300, Sarah Milani wrote:
>>>>
>>>> Sim, o servidor que está apresentando este evento no log é virtualizado, vou dar olhada nos logs do host que hospeda ele pra vê se acho alguma info e te aviso.
>>>>
>>>> Desde já agradeço, pela atenção.
>>>>
>>>> ;)
>>>>
>>>>
>>>> Em 25 de novembro de 2014 16:57, Rodrigo B Brasil <rodrigobbrasil@gmail.com> escreveu:
>>>>
>>>> Oi Sarah,
>>>>
>>>> Não tenho como confirmar agora pra ti se as máquinas estão com esse problema nessa release do kernel, mas eu tenho quase certeza que sim (visto que essa release é de março). Portanto, a atualização não resolveria.
>>>>
>>>> Eu fui mais a fundo do problema e constatei que o erro de "task abort" que é exibido nos SOs também é exibido nos logs dos hosts VMware onde esses guests estão. Tu também usas algum tipo de virtualização? Já vi isso acontecendo com KVM também.
>>>>
>>>> --
>>>> Rodrigo Bezerra Brasil
>>>> Belém, PA, BR
>>>>
>>>> “Software livre” é uma questão de liberdade, não de preço. Para entender o conceito, pense em “liberdade de expressão”, não em “cerveja grátis”.
>>>>
>>>> OpenPGP hex keyID: 0xB05DAFA91AA38CA7
>>>>
>>>> 2014-11-25 16:27 GMT-03:00 Sarah Milani <sarah.milani@gmail.com>:
>>>>
>>>> Boa Tarde,
>>>>
>>>>
>>>> Tenho identificado este mesmo evento (http://lists.centos.org/pipermail/centos-pt-br/2014-April/005256.html) em um dos meus servidores de aplicação:
>>>>
>>>> CentOS release 6.4 (Final)
>>>> mptlinux-3.04.20
>>>> Fusion MPT base driver
>>>> Fusion MPT SPI host driver
>>>>
>>>>
>>>> Nov 25 14:33:37 kernel: mptscsih: ioc0: attempting task abort! (sc=ffff880218f151c0)
>>>> Nov 25 14:33:37 kernel: sd 2:0:0:0: [sda] CDB: Read(10): 28 00 00 3e 68 b0 00 00 10 00
>>>> Nov 25 14:33:37 kernel: mptscsih: ioc0: task abort: SUCCESS (rv=2002) (sc=ffff880218f151c0)
>>>> Nov 25 14:39:14 kernel: mptscsih: ioc0: attempting task abort! (sc=ffff88096c4fe5c0)
>>>>
>>>>
>>>> Gostaria de saber, se a atualização do kernel para 2.6.32-431.11.2.el6.centos.plus.x86_64, resolveu o problema.
>>>>
>>>>
>>>> Desde já agradeço,
>>>>
>>>> --
>>>>
>>>> Atenciosamente,
>>>>
>>>> Sarah Milani
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> CentOS-pt-br mailing list
>>>> CentOS-pt-br@centos.org
>>>> http://lists.centos.org/mailman/listinfo/centos-pt-br
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> CentOS-pt-br mailing list
>>>> CentOS-pt-br@centos.org
>>>> http://lists.centos.org/mailman/listinfo/centos-pt-br
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Atenciosamente,
>>>>
>>>> Sarah Milani
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> CentOS-pt-br mailing list
>>>> CentOS-pt-br@centos.org
>>>> http://lists.centos.org/mailman/listinfo/centos-pt-br
>>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Att:
>>> Cleiton Alves
>>> :(){ :|:& };:
>>> echo "b"> /proc/sysrq-trigger
>>> _______________________________________________
>>> CentOS-pt-br mailing list
>>> CentOS-pt-br@centos.org
>>> http://lists.centos.org/mailman/listinfo/centos-pt-br
>>>
>>
>>
>>
>> --
>> Atenciosamente,
>>
>> Sarah Milani
>>
>>
>
> --
> Atenciosamente,
> Rodrigo da Silva Cunha
>
>
>
--Atenciosamente,
Rodrigo da Silva Cunha
_______________________________________________
CentOS-pt-br mailing list
CentOS-pt-br@centos.org
http://lists.centos.org/mailman/listinfo/centos-pt-br
----------------------------------
"O que vale é a intensidade do fôlego que se toma para grandes realizações!"
Thanks God.
@little_oak
http://www.appunix.com.br
_______________________________________________
CentOS-pt-br mailing list
CentOS-pt-br@centos.org
http://lists.centos.org/mailman/listinfo/centos-pt-br