O módulo da Web ou servidor de aplicativos pára de processar os pedidos
Se um processo do servidor de aplicativos fecha espontaneamente ou os módulos da Web pararem de responde a novas solicitações, é importante que você rapidamente determine porque esta parada está ocorrendo. Você pode utilizar alguma das técnicas a seguir para determinar se o problema é um problema do módulo da Web ou um problema do ambiente do servidor de aplicativos.
- Tente Isolar o problema instalando os módulos da Web em diferentes servidores, se possível.
Verifique na estrutura de diretórios do produto um arquivo com um nome semelhante a javacore[number].txt. Esse é um arquivo de dump de encadeamento Java™ que a JVM criará se um processo do servidor de aplicativos for fechado espontaneamente.
Se um processo do servidor de aplicativos fechar espontaneamente, haverá um SDUMP para você analisar.
- Utilize o Tivoli Performance
Viewer para determinar se algum dos recursos do servidor de aplicativos, como o
heap Java, ou as conexões com o banco de dados, atingiram sua capacidade máxima. Se houver um problema de recurso, revise o código do aplicativo para obter uma possível causa:
- Se conexões com o banco de dados estiverem sendo designadas para um pedido, mas não estiverem sendo liberadas quando os pedidos finalizam o processamento, certifique-se de que o código do aplicativo execute close() em todos os objetos Connection abertos de um bloco finally{}.
- Se houver um crescimento contínuo de encadeamentos do mecanismo de servlet em utilização, verifique nos blocos de código synchronized do aplicativo possíveis condições de congelamento.
- Se houver um crescimento contínuo no tamanho de heap de uma JVM, verifique no código do aplicativo oportunidades de fuga de memória, como coleções estáticas (nível de classe), que podem fazer com que objetos nunca sejam coletados para o lixo.
- Ative a coleta de lixo detalhada na instalação do servidor de
aplicativos para ajudá-lo a determinar se há problemas de fuga de memória. Esse recurso inclui instruções detalhadas ao arquivo de log de erros da JVM sobre a quantidade de memória disponível e em utilização. Para ativar a coleta de lixo detalhada:
No console administrativo, clique em server_name. Em seguida, em Server Infrastructure, clique em , e selecione Coleta de lixo detalhada.
No console administrativo, clique em server_name. Em seguida, na seção Server Infrastructure, clique em , e selecione Coleta de lixo detalhada.
- Pare e reinicie o servidor de aplicativos.
- Periodicamente, procure no arquivo de log instruções de coleta de lixo. Procure por instruções iniciando com "falha de alocação". Essa cadeia indica que a necessidade de alocação de memória acionou uma coleta de lixo da JVM para liberar memória não utilizada. As falhas de alocação são normais e não indicam necessariamente um problema. No entanto, a instrução de falha de alocação é seguida por instruções que mostram quantos bytes são necessários e quantos são alocados. Se essas instruções de bytes necessários indicarem que a JVM continua alocando mais memória para seu próprio uso ou que a JVM não pode alocar a quantidade de memória necessária, poderá haver uma fuga de memória.
Também é possível utilizar o Tivoli Performance Viewer para detectar problemas de fuga de memória.
Determine se o servidor de aplicativos está sem memória. Se você determinar que o servidor de aplicativos está sem memória, poderá estar ocorrendo uma das seguintes situações:
- Há uma fuga de memória no código do aplicativo que deve ser abordado. Para indicar
a causa de uma fuga de memória, ative a propriedade RunHProf na página Java
Virtual Machine do console administrativo. server_name é o nome do servidor de aplicativos com problema. Após ativar a propriedade RunHProf, é necessário:
- Configure o campo Argumentos HProf para um valor semelhante a depth=20,file=heapdmp.txt. Esse valor mostra pilhas de exceção até, no máximo, 20 níveis e salva a saída heapdump no arquivo app_root/bin/heapdmp.txt.
- Salve as definições.
- Pare e reinicie o servidor de aplicativos.
- Se possível, recrie o cenário ou acesse o recurso que fez com que o processo do servidor de aplicativos espontaneamente fechasse ou seus módulos da Web parassem de responder a novas solicitações. Em seguida, pare o servidor de aplicativos. Se não for possível reconstituir o cenário ou acessar o recurso, aguarde até que o problema recorra e, em seguida, pare o servidor de aplicativos.
- Examine o arquivo no qual o dump do heap foi salvo. Por exemplo, examine o
arquivo app_root/bin/heapdmp.txt:
- Procure pela sequência, "SITES BEGIN". Isso procura a localização de uma lista de objetos Java na memória, que mostra a quantidade de memória alocada aos objetos.
- A lista de objetos Java ocorre toda vez que houver uma alocação de memória na JVM. Há um registro de qual tipo de objeto a memória instanciou e um identificador de uma pilha de rastreio, listada em outro lugar no dump, que mostra o método Java que fez a alocação.
- A lista de objetos Java está na ordem decrescente por número de bytes alocados. Dependendo da natureza da fuga, a classe do problema deve aparecer perto do início da lista, mas nem sempre é o caso. Procure em toda a lista as grandes quantidades de memória ou instâncias frequentes da mesma classe sendo instanciada. Em último caso, utilize o ID da coluna pilha de rastreio para identificar alocações que ocorrem repetidamente na mesma classe e no mesmo método.
- Examine no código fonte indicado nas pilhas de rastreio relacionadas a possibilidade de fugas de memória.
- A JVM está utilizando o tamanho máximo do heap permitido para uso. Nesta situação, você deve aumentar a configuração de tamanho máximo do heap para o servidor de aplicativos se tiver armazenamento suficiente disponível para isso.
- O tempo de execução do servidor está apresentando um problema. Se você determinar que há um problema com o tempo de execução do servidor, certifique-se de que tenha aplicado toda as atualizações de serviço do produto. Se, após a aplicação de todas as atualizações de serviço, o problema continuar, entre em contato com o IBM® Support.
- Há uma fuga de memória no código do aplicativo que deve ser abordado. Para indicar
a causa de uma fuga de memória, ative a propriedade RunHProf na página Java
Virtual Machine do console administrativo. server_name é o nome do servidor de aplicativos com problema. Após ativar a propriedade RunHProf, é necessário:
Procure pistas no dump de encadeamentos:
A JVM cria um dump de encadeamento sempre que um processo do servidor de aplicativos é fechado espontaneamente. Você também pode forçar que um aplicativo crie um dump de encadeamento. Depois de um dump ser criado, você pode verificá-lo para obter pistas sobre por que novos pedidos não estão sendo processados.
Para forçar um dump de encadeamento:
- Utilizando o prompt de comando wsadmin, obtenha um identificador para o
servidor de aplicativo do problema:
wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=server_name,*]
em que server_name é o nome do seu servidor.
- Gere o dump de encadeamentos:
wsadmin>$AdminControl invoke $jvm dumpThreads
Nota: O comando dumpThreads cria outros tipos de arquivos dump dependendo das configurações de -Xdumps. A saída de dump varia dependendo da plataforma e pode incluir arquivos principais do sistema, heap e dumps snap. Procure um arquivo de saída no diretório profile_root/logs com o nome como javacore.jobnum.jobuser.jobname.timestamp.txt.
Procure um arquivo de saída no diretório raiz da instalação do produto com um nome semelhante a javacore.date.time.id.txt.
Depois do aplicativo criar o dump, você pode verificar as seguintes pistas:
As sequências "Error" ou "exception information" no início do arquivo. Essas cadeias indicam o encadeamento que causou o fechamento espontâneo do processo do servidor de aplicativos. Essas cadeias não estarão presentes se você tiver forçado o dump.
Procure um tamanho de heap excessivo atual. O dump de encadeamentos mostra informações sobre o tamanho do heap do Java atual, e as configurações dos tamanhos máximo e mínimo de heap.
Olhe a captura instantânea de cada encadeamento no processo. O dump de encadeamento contém uma snapshot de cada encadeamento no processo, iniciando na seção entitulada "Dump de encadeamento integral".
- Procure por encadeamentos com uma descrição que contém "state:R". Esses encadeamentos estão ativos e em execução quando o dump é forçado ou o processo encerrado.
- Procure vários encadeamentos na mesma localização de origem do código do aplicativo Java. Vários encadeamentos da mesma localização podem indicar uma condição de congelamento (vários encadeamentos aguardando em um monitor) ou um loop infinito e ajudam a identificar o código do aplicativo que tem o problema.
Consulte a instantânea de cada encadeamento no processo. O dump de encadeamento contém um snapshot de cada encadeamento no processo, iniciando na seção entitulada "Informações do encadeamento".
- Procure encadeamentos que estejam aguardando bloqueios mantidos por outros encadeamentos.
- Procure vários encadeamentos na mesma localização de origem do código do aplicativo Java. Vários encadeamentos da mesma localização podem indicar uma condição de congelamento (vários encadeamentos aguardando em um monitor) ou um loop infinito e ajudam a identificar o código do aplicativo que tem o problema.
É normal que determinados componentes no tempo de execução do produto tenham determinados tipos de encadeamentos no mesmo local de origem do código Java. Esses componentes incluem o contêiner da Web, o contêiner EJB e o conjunto de encadeamentos ORB.
- Utilizando o prompt de comando wsadmin, obtenha um identificador para o
servidor de aplicativo do problema: