Avalados por :
Temos um portal em funcionamento com a última versão do JDK (Linux X86_64, IBM JDK SR9), com os parâmetros recomendados configurados e ainda enfrentamos muitos problemas de estabilidade. O portal tem três processos de servidor, e o que vemos na realidade é que dois deles consomem 100% da CPU cada. Atualmente, ninguém está conectado ao portal. Posso ver mensagens "estranhas" no rastreamento padrão como
sistema predecesor -
com.sap.engine.services.applocking.exception.AppLockingTechnicalLockException: A duração não pode ser a sessão do usuário, pois atualmente não há nenhum usuário conectado. Não é permitido criar bloqueios para o usuário do sistema
.
em com.sap.engine.services.applocking.AbstractBaseLocking.getObjectForLifetime(AbstractBaseLockin
g.java:483)
em com.sap.engine.services.applocking.LogicalLockingImpl.getCurrentLifetimeDescription(LogicalLoc
kingImpl.java:193)
em com.sap.engine.services.applocking.AbstractBaseLocking.lockInternal(AbstractBaseLocking.java:1
28)
em com.sap.engine.services.applocking.LogicalLockingImpl.lock(LogicalLockingImpl.java:43)
em com.sap.engine.services.applocking.NamespaceLogicalLockingImpl.lock(NamespaceLogicalLockingImp
l.java:47)
em com.sap.engine.services.applocking.LogicalLocking_Stub.lock(LogicalLocking_Stub.java:65)
em com.sapportals.wcm.service.taskqueue.TaskQueue$Lock.lock(TaskQueue.java:316)
em com.sapportals.wcm.service.taskqueue.TaskQueue$Lock.writeLock(TaskQueue.java:293)
em com.sapportals.wcm.service.taskqueue.TaskQueue.writeLock(TaskQueue.java:467)
em com.sapportals.wcm.service.taskqueue.TaskQueue.get(TaskQueue.java:122)
em com.sapportals.wcm.service.taskqueue.TaskQueueReader.get(TaskQueueReader.java:68)
em com.sapportals.wcm.service.taskqueue.TaskQueueReader.get(TaskQueueReader.java:58)
em com.sapportals.wcm.service.jobprocessor.LocalDispatcher.stopJobs(LocalDispatcher.java:161)
em com.sapportals.wcm.service.jobprocessor.LocalDispatcher.run(LocalDispatcher.java:101)
em java.lang.Thread.run(Thread.java:838)
os dois processos do servidor estão "em loop" em algum lugar, o sistema de arquivos está saturado com esses arquivos de registro, 4 ou 5 de default.trc.X a cada minuto.
Reiniciar o portal NÃO é uma opção, pois esse problema surgirá tarde ou cedo novamente.
O que podemos fazer como CLIENTE além de criar despejos de threads e anexá-los a uma chamada OSS e "esperar"? Como descobrir o que o sistema está fazendo?
Markus
Olá David,
Obrigado por esse link, vou tentar.
Isso também funciona com o JDK da IBM? Estamos em 64 bits aqui...
--
Markus
Compreendo a tua dor.
Parece semelhante a uma situação que tive há algum tempo, quando algo estava sobrecarregando as CPUs e consumindo memória.
Aqui tens um visualizador de coleta de lixo:
http://www.tagtraum.com/gcviewer-download.html
Faz o download da versão que preferires e adiciona as linhas -Xloggc:<arquivo> -XX:+PrintGCDetails no início. Isso criará um arquivo no servidor0 (ou em qualquer número de servidor). Abre esse diretório para navegar e executa o visualizador no teu laptop. Conseguirás ver o momento exato em que o servidor começa a ficar louco e assim identificar os erros gerados nesse momento.
Obrigado pela sua resposta.
Sim, consigo/posso fazer login, temos três processos de servidor e dois deles estavam/estão nesse estado. O suporte me informou que esses processos estavam apenas realizando coleta de lixo e, devido à máquina estar paginando dentro e fora do arquivo de troca, a coleta de lixo não conseguia "terminar" antes que o próximo processo começasse.
Duvido disso porque ao verificar a E/S na máquina (usando iostat 1) não mostrou nenhuma E/S grande.
Enquanto isso, reiniciamos a instância, está funcionando até agora, mas ainda não consigo acreditar que não há maneira de verificar o que a caixa está fazendo. Verifiquei a conexão de rede e além do meu telnet, não havia outra conexão com o sistema (netstat -t | grep -v `hostname`) - então o sistema estava ocupado consigo mesmo.
Estou perdendo cada vez mais confiança nesse J2EE porque não recebo muita ajuda do suporte além de "instalar as últimas correções" e "instalar os últimos patches do webdynpro", o que nem sempre é possível e não é de muita ajuda (embora as pessoas estejam fazendo o máximo para ajudar, sem dúvida).
O que realmente me deixa louco é o fato de NÃO HÁ MANEIRA de descobrir o que um processo está fazendo além de criar dumps de threads e enviá-los para o suporte e "esperar" - ou tentar copiar os dumps para uma caixa do Windows e abri-los no analisador de dumps de threads e começar a "adivinhar".
A configuração é puramente padrão, J2EE, Portal, ESS (configurado usando sapinst), sem NWDI, sem aplicativos desenvolvidos por nós mesmos, apenas o padrão simples, o dimensionamento também está correto, uma caixa desse tipo poderia facilmente lidar com algumas centenas de usuários de diálogo ABAP.
Tem sido uma experiência frustrante no geral e está ficando pior a cada dia que olho para uma dessas instâncias de J2EE, a documentação disponível está espalhada por toda parte (help.sap.com, notas, /rkt...) e é muito superficial, o que significa que você não obtém informações sobre como algo se relaciona, como algo interage com o quê, etc.
O cliente é mantido na ignorância de propósito e assim nunca está em uma posição para se ajudar, e tudo isso por um software tão promovido pela palavra da moda pelo qual pagamos tanto dinheiro.
Desculpe, me desviei do assunto, não quis ser grosseiro, mas todo esse software de "clique aqui e depois ali" não é muito útil se você não conhece o contexto, simplesmente está perdido.
--
Markus
O portal está funcionando corretamente?
Você consegue fazer login como usuário ou administrador?
contacto@primeinstitute.com
(+51) 1641 9379
(+57) 1489 6964
© 2024 Copyright. Todos los derechos reservados.
Desarrollado por Prime Institute
