Enfim, meninos...valeu pelas dicas, anotei algumas aqui pra quando me deparar com este problema novamente. No entanto, depois que os arquitetos alteraram um parâmetro na própria aplicação para reduzir a frequência de escrita em logs e banco, não identifiquei mais este evento. ^^ Acredito que deu pra contornar com este procedimento.
Em 1 de dezembro de 2014 00:33, João Paulo (littleoak) whilelive@gmail.com escreveu:
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 http://xn--mo-sia.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.twitter.com/little_oak http://www.appunix.com.br http://www.webking.com.br
CentOS-pt-br mailing list CentOS-pt-br@centos.org http://lists.centos.org/mailman/listinfo/centos-pt-br