Estou experimentando uma falta de resposta periódica no tomcat em nosso ambiente de produção. Não consigo reproduzir isso em um ambiente de teste e nada aparece nos logs antes ou durante o evento. O Tomcat continua em execução, mas para de atender aos pedidos. Eu li este segmento e coloquei as opções de saída de coleta de lixo em JAVA_OPTS, embora eu ainda não reiniciei o tomcat para colocá-los em prática. Minha situação é diferente em que tomcat / jvm aparentemente não irá recuperar ou "acordar". Confirmei que nosso aplicativo não respondeu por pelo menos 15 minutos em várias ocasiões. A solução é sempre reiniciar o tomcat (usando daemontools). A frequência varia, às vezes durante o pico de carga e, às vezes, no meio da noite (carga muito leve).
Eu permiti até 4g de memória para o jvm (-Xms2g -Xmx4g). O servidor tem 16g de memória e está executando o jvm de 64 bits. Documento técnico da Sun sobre as declarações de ajuste do Java: "É muito provável que comprometer muito a memória física de um sistema resulte na paginação da memória virtual para o disco, muito provavelmente durante as operações de coleta de lixo, levando a problemas significativos de desempenho ". Estou definindo o tamanho de heap muito grande? Eu me beneficiaria de definir o tamanho mínimo para ser o mesmo que o máximo?
Eu não acredito que o sistema esteja trocando memória em disco. A saída do free -m não mostra nenhum uso de swap, e eu configurei o swappiness como 0 no sistema.
Quando a falta de resposta ocorreu às 2h30 desta manhã, executei um jstat e um ps rápidos antes de reiniciar o tomcat:
O jstat mostrou valores semelhantes ao que é agora, com algumas exceções: o YGC era 431 contra 44 agora, o YGCT 10/1, o FGC 59/7, o FGCT 39/2, o GCT 49/3
A saída de ps mostrou 1422832 residentes e 5723580 de uso de memória virtual. Isso se compara com 1390036 e 5642668 de ontem durante a operação normal.
Eu não sou especialista em nada disso, então qualquer ajuda seria apreciada.
UPDATE: Ok, adicionei o seguinte a JAVA_OPTS e reiniciei o tomcat momentaneamente:
-XX: + UseConcMarkSweepGC -Xms2g -Xmx2g -verbose: gc -XX: + PrintGCTimeStamps -XX: + PrintGCDetails
As mudanças são: 1) algoritmo swich gc. 2) diminuir o tamanho máximo do heap, pois parece que não preciso de 4g e, aparentemente, overcommitting pode causar gc massivo periódico. 3) Ligue o logging do vebose gc. Obrigado a todos.
Para começar, aqui está um link útil em "Ajustando a coleta de lixo com o Java 5.0 Java ™ Máquina Virtual "
Isso soa como o GC pausa fazendo o tomcat não responder. Uma coisa é começar com um coletor de lixo de "baixa pausa" com a opção -XX:+UseConcMarkSweepGC .
Vimos isso em nosso ambiente de produção algumas vezes, e acabou sendo a coleta de lixo do java interrompendo solicitações adicionais. A maior diferença para nós foi o uso de 100% do processador em pelo menos um dos núcleos pela duração do período sem resposta.
A resposta no nosso caso foi rastrear um vazamento de memória no aplicativo. Não estou certo de que isso seja uma resposta para você, mas é pelo menos outro ponto de dados.