NÓS todos estão desenvolvendo a aplicação do jave para a vária área porque é uma da plataforma segura e non-hackle. Portanto, é considerar a plataforma de programação mais segura para escolher. Aqui um de nossos servidores foi pesadamente carregado e nós não encontramos nenhumas razões específicas acontecer isto. Ao mesmo tempo observado a CPU consumida pesadamente e RAM é mal usado. Por isso, parece que algum vazamento de memória ou código de freio acontecendo na extremidade do servidor web, como não vimos qualquer conjunção de carga no final do servidor web.

Portanto, precisamos explorar o problema coletando os dados da coleção de lixo para um arquivo. Com base nas informações que eu tinha dado, Existem 3 tipos básicos de dados que precisamos identificar a causa raiz de um aplicativo Java.

1. Recolha do depósito Heap
Isto é basicamente puxar o que todos os dados estão presentes na memória do sistema. Portanto, isso nos ajudaria a identificar qual função / código está atualmente carregado na memória.

Como faço para executar dump de thread: Execute o comando abaixo

/ Var / jdk / bin / jmap -histo $ (pgrep java)> ~ / heapdump _ $ (data + “% Y-% m-% d_% H% M”). Log

O comando acima irá puxar os dados de despejo headp para um arquivo separado datado para referência futura.

2. Recolha de despejo de thread
Isso é basicamente usado para identificar as bibliotecas / funções / formas de programação que estão sendo usadas naquele tempo específico. Isso será muito útil para identificar a funcionalidade corrigir ou freios. Portanto, tínhamos instruído a manter esses dados estritamente em cima de qualquer interrupção da aplicação.

 

  • Como puxar o despejo Thread

 

/ Var / jdk / bin / jstack -l $ (pgrep java)> ~ / thread_dump _ $ (data + “% Y-% m-% d_% H% M”). Log

Nota: Este comando irá puxar o backup de todo o segmento java sendo executado na memória e gravá-lo como um arquivo datado. Você também precisa levar esses registros por um período de tempo para entender o histórico da função carregada na memória. Então eu usei para executar este comandos 3 vezes em um intervalo de um minuto.

3. A verificação da aplicação java é muito utilizada com o jstat.

Existe um utilitário (jstat) que recolhe as estatísticas de dados de coleta de lixo, incluindo o gcutils (usado para verificar o uso de áreas de heap, o número de GC realizado e o tempo total acumulado para operações de GC).

[Root @ web232 ~] # / var / jdk / bin / jstat -gcutil $ (pgrep java) 250 700
S0 S1 E O P YGC YGCT FGC FGCT GCT
0,00 76,33 100,00 100,00 38,71 133 15,991 229 1465,177 1481,168
0,00 76,33 100,00 100,00 38,71 133 15,991 229 1465,177 1481,168
0,00 94,96 100,00 100,00 38,71 133 15,991 229 1466,212 1482,203
0,00 100,00 100,00 100,00 38,71 133 15,991 230 1466,212 1482,203
0,00 100,00 100,00 100,00 38,71 133 15,991 230 1466,212 1482,203
0,00 100,00 100,00 100,00 38,71 133 15,991 230 1466,212 1482,203
0,00 100,00 100,00 100,00 38,71 133 15,991 230 1466,212 1482,203
0,00 100,00 100,00 100,00 38,71 133 15,991 230 1466,212 1482,203

Os logs acima mostrando que O ld espaço e E den espaço foi totalmente ocupado por GC ciclo. Portanto, qualquer solicitação de GC pendente será mantida na fila e o servidor web permanece em execução nos estados pendentes, mesmo que ele esteja funcionando corretamente. O único culpado é GC coleção matando o servidor web e mantê-lo forzhen. Então, reiniciar o servidor web irá ajudar a liberar o GC e, portanto, plataforma trazê-lo de volta rapidamente.

Se você ver o espaço Eden (E) e a área Velha (O) estão mostrando o valor 100. sua aplicação foi conduzida com mau desempenho e pode não estar funcionando corretamente. Assim, as opções são reiniciar o servidor web ou matar o processo jave.

Como faço para matar o processo java.

/ Bin / kill -9 $ (pgrep java)
Anúncios