Ajustando a IBM Virtual Machine para Java
Um servidor de aplicativos é um servidor baseado em Java™ e requer um ambiente JVM (Java Virtual Machine) para executar e suportar os aplicativos corporativos que são executados nele. Como parte da configuração do seu servidor de aplicativos, é possível configurar o Java SE Runtime Environment para ajustar o uso do recurso do sistema e do desempenho. Esse tópico se aplica às máquinas virtuais IBM® para Java.
Antes de Iniciar
- Determine o tipo de JVM no qual seu servidor de aplicativos está em execução.
Emita o comando java –fullversion a partir do diretório app_server_root/java/bin do servidor de aplicativos.
Em resposta a esse comando, o Java grava informações sobre a JVM, incluindo as informações do provedor JVM, na janela na qual o comando é executado, por exemplo:
java full version "JRE 1.6.0 IBM Windows 32 build pwi3260sr7-20091217_01 (SR7)"
Em resposta a esse comando, a Java grava informações sobre a JVM, incluindo as informações do provedor JVM, em stderr.
Emita o comando dspwasinst a partir do diretório profile_root/bin. A saída desse comando contém a configuração JAVA_HOME e outras informações sobre a JVM ativada para seu perfil do servidor de aplicativos.
Se seu servidor de aplicativos estiver em execução em um Sun HotSpot JVM, consulte o tópico Ajustando o Sun HotSpot Java virtual machines (Solaris & HP-UX).
Use o comando managesdk, se desejar ativar seu perfil do servidor de aplicativos para usar uma JVM diferente.
Verifique se:
- A versão suportada mais recente da JVM está instalada no sistema.
- A atualização do serviço mais recente está instalada no sistema. Praticamente cada novo nível de serviço inclui melhorias no desempenho da JVM.
Verifique se a atualização de serviço mais recente está instalada em seu sistema. Praticamente cada novo nível de serviço inclui melhorias no desempenho da JVM.
Sobre Esta Tarefa
Cada fornecedor de JVM fornece informações detalhadas sobre o desempenho e o ajuste de sua JVM. Use as informações fornecidas neste tópico junto com as informações fornecidas com a JVM que está em execução em seu sistema.
Tanto o controlador quanto o servidor contêm uma
JVM. As informações contidas neste tópico aplicam-se apenas à JVM no
servidor. Normalmente, a JVM no controlador não precisa ser ajustada.
Um Java SE Runtime Environment fornece o ambiente para executar aplicativos corporativos e servidores de aplicativos. Portanto, a configuração Java desempenha uma função significativa na determinação do desempenho e do consumo de recursos do sistema para um servidor de aplicativos e os aplicativos que são executados nele.
O IBM virtual machine for Java Versão 6.0 inclui o que há de mais recente nas especificações da Java Platform, Enterprise Edition (Java EE), e fornece melhorias de desempenho e estabilidade sobre versões anteriores da Java.
Embora o ajuste da JVM dependerá do provedor de JVM que utilizará, certos conceitos gerais se aplicam a todas as JVM. Estes conceitos gerais incluem:
- Ajuste do compilador. Todas as JVMs utilizam compiladores Just-In-Time (JIT) para compilar os códigos de byte Java em instruções nativas durante o tempo de execução do servidor.
- Ajuste de memória ou heap Java. O ajuste da função de gerenciamento da memória da JVM, ou coleta de lixo, é um bom ponto de partida para aprimorar o desempenho da JVM.
- Ajuste de carregamento de classe.
- Inicialização versus otimização do desempenho de tempo de execução
As seguintes etapas fornecem instruções específicas sobre como executar os seguintes tipos de ajuste para cada JVM. As etapas não têm que ser executadas em qualquer ordem específica.
Procedimento
Limite o número de dumps que são executados em situações específicas.
Em determinadas condições de erro, vários encadeamentos do servidor de aplicativos poderão falhar e a JVM solicita um TDUMP para cada um desses encadeamentos. Se um número significativo de encadeamentos falhar ao mesmo tempo, o número resultante de TDUMPs obtidos simultaneamente pode levar a outros problemas do sistema. falta de armazenamento auxiliar. Use a variável de ambiente JAVA_DUMP_OPTS para especificar o número de dumps que você quer que a JVM produza em certas situações. O valor especificado para essa variável não afeta o número de TDUMPS que são gerados devido às chamadas com.ibm.jvm.Dump.SystemDump() de aplicativos que estão em execução no servidor de aplicativos.
Por exemplo, se você quiser configurar a JVM de modo que ela:- Limite o número de TDUMPs obtidos a um
- Limite o número de JAVADUMPs obtidos a no máximo três
- Não capture nenhuma documentação se ocorrer uma INTERRUPÇÃO
Então, configure a variável JAVA_DUMP_OPTS com o seguinte valor:JAVA_DUMP_OPTS=ONANYSIGNAL(JAVADUMP[3],SYSDUMP[1]),ONINTERRUPT(NONE)
- Otimize o desempenho da inicialização e do tempo de execução.
Em alguns ambientes, como um ambiente de desenvolvimento, é mais importante otimizar o desempenho de inicialização do servidor de aplicativos em vez do desempenho de tempo de execução. Em outros ambientes, é mais importante otimizar o desempenho de tempo de execução. Por padrão, as IBM virtual machines para Java são otimizadas para desempenho de tempo de execução, enquanto as JVMs baseadas em HotSpot são otimizadas para desempenho de inicialização.
O compilador Java Just-in-Time (JIT) exerce impacto na possibilidade de otimização do desempenho de inicialização ou do tempo de execução. O nível de otimização inicial que o compilador usa influencia na quantidade de tempo necessária para a compilação de um método de classes e na quantidade de tempo que é necessária para iniciar o servidor. Para inicializações mais rápidas, reduza o nível de otimização inicial usado pelo compilador. Entretanto, se você reduzir o nível de otimização inicial, o desempenho do tempo de execução dos seus aplicativos poderá diminuir porque os métodos de classe agora são compilados em um nível de otimização reduzido.
- -Xquickstart
Esta configuração influencia como a máquina virtual IBM para Java usa um nível de otimização reduzido para compilações de método de classe. Um nível de otimização inferior fornece inicializações mais rápidas do servidor, mas diminui o desempenho do tempo de execução. Se esse parâmetro não for especificado, a IBM virtual machine para Java assume como padrão a inicialização com um alto nível de otimização inicial para compilações, o que resulta em desempenho de tempo de execução mais rápido, mas inicializações do servidor mais lentas.
Essa propriedade pode ser configurada no painel Java virtual machine usando o console administrativo. Para obter detalhes, leia as informações sobre as configurações da Java virtual machine.
Informações Valor Padrão Alto nível de otimização inicial do compilador Recomendado Alto nível de otimização inicial do compilador Uso A especificação de -Xquickstart melhora o tempo de inicialização do servidor.
Para acelerar a inicialização da JVM e melhorar o tempo de inicialização do servidor, especifique os seguintes argumentos de linha de comandos no campo Argumentos Gerais da JVM na seção Propriedades Gerais da Guia de Configuração.
-Xquickstart -Xverify:none
- -Xquickstart
- Configure o tamanho de heap.
Os parâmetros da heap Java influenciam o comportamento da coleta de lixo. Aumentar o tamanho do heap suporta a criação de mais objetos. Como um heap grande demora mais para ser preenchido, o aplicativo é executado durante mais tempo antes de ocorrer uma coleta de lixo. Contudo, um heap maior também leva mais tempo para ser compactado e faz com que a coleta de lixo demore mais.
A JVM usa limites definidos para gerenciar o armazenamento que é alocado. Quando os limites são atingidos, o coletor de lixo é chamado para liberar o armazenamento não usado. Portanto, a coleta de lixo pode causar degradação significativa do desempenho do Java. Antes de alterar os tamanhos de heap inicial e máximo, você deve considerar as seguintes informações :- Na maioria dos casos, você deve configurar o tamanho de heap máximo da JVM para um valor superior ao tamanho de heap inicial da JVM. Essa configuração permite que a JVM opere de forma eficiente durante períodos normais de estado estável dentro dos limites do heap inicial. Essa configuração também permite que a JVM opere de forma eficiente durante períodos de alto volume de transação, pois a JVM pode expandir o heap até o valor especificado para o tamanho de heap máximo da JVM. Em alguns casos, em que o desempenho ideal absoluto é obrigatório, você pode querer especificar o mesmo valor para o tamanho de heap inicial e máximo. Essa configuração elimina gastos adicionais que ocorrem quando a JVM expande ou contrai o tamanho de seu heap. Antes de alterar qualquer tamanho de heap da JVM, verifique a alocação de armazenamento da JVM é grande o suficiente para acomodar o novo tamanho de heap.
- Não deixe o tamanho do heap inicial muito grande de modo que, embora inicialmente isso melhore o desempenho através do atraso da coleta de lixo, quando a coleta de lixo não ocorrer, o processo de coleta afete o tempo de resposta porque o processo tem execução mais longa.
As informações da heap Java estão contidas em registros SMF e podem ser visualizadas dinamicamente usando o comando de console DISPLAY,JVMHEAP.
Para utilizar o console administrativo para configurar o tamanho de heap:
- No console administrativo, clique em Servidores>Tipos de Servidor>Servidores de Aplicativos do WebSphere> server_name.
Na seção Infraestrutura do Servidor, clique em Gerenciamento Java e de Processo > Definição de Processo > Java Virtual Machine.
Na seção Infraestrutura do Servidor, clique em Gerenciamento Java e de Processo > Definição de Processo.
Selecione Controle ou Servidor e selecione Java Virtual Machine.
- Especifique um novo valor no campo Tamanho de Heap Inicial ou
Tamanho de Heap Máximo.
Você também pode especificar valores para ambos os campos, se precisar ajustar ambas as configurações.
Para análise de desempenho, os tamanhos de heap inicial e máximo devem ser iguais.
A configuração Tamanho de Heap Inicial especifica, em megabytes, a quantidade de armazenamento que é alocada para o heap da JVM quando a JVM é iniciada. A configuração Tamanho de Heap Máximo especifica, em megabytes, a quantidade máxima de armazenamento que pode ser alocada para o heap da JVM. Ambas as configurações têm um efeito significativo no desempenho.
Se estiver ajustando um sistema de produção do qual você desconhece o tamanho do conjunto de trabalhos dos aplicativos corporativos que estão em execução nesse sistema, um valor inicial apropriado para o tamanho de heap inicial é 25 por cento do tamanho máximo do heap. A JVM tenta então adaptar o tamanho do heap ao tamanho do conjunto de trabalho do aplicativo.
A ilustração a seguir representa três perfis de CPU, cada um deles executando uma carga de trabalho fixa com configurações variadas de heap Java. No perfil do meio, os tamanhos de heap inicial e máximo são configurados para 128 MB. Quatro coletas de lixo ocorrem. O tempo total na coleta de lixo é cerca de 15 por cento da execução total. Quando os parâmetros de heap são dobrados para 256 MB, como no perfil superior, a duração do horário de trabalho aumenta entre as coletas de lixo. Somente três coletas de lixo ocorrem, mas o tempo de cada coleta de lixo também aumenta. No terceiro perfil o tamanho do heap é reduzido para 64 MB e exibe o efeito oposto. Com um tamanho de heap menor, tanto o tempo entre coletas de lixo quanto o tempo para cada coleta de lixo são mais curtos. Para todas as três configurações, o tempo total na coleta de lixo é de aproximadamente 15 por cento. Esse exemplo ilustra um conceito importante sobre a heap Java e seu relacionamento com o uso de objeto. Sempre existe um custo para a coleta de lixo quando se executa aplicativos corporativos.
Execute uma série de testes que verificam as configurações da heap Java. Por exemplo, faça experiências com execuções de 128 MB, 192 MB, 256 MB e 320 MB. Durante cada experiência, monitore o total de utilização de memória. Se você expandir o heap com muito rigor, poderá ocorrer uma paginação.
Use o comando vmstat ou o Windows Performance Monitor para verificar a paginação. Se ocorrer paginação, reduza o tamanho do heap ou adicione mais memória ao sistema.
Use o comando IBM i WRKSYSSTS para verificar a paginação. Se ocorrer paginação, reduza o tamanho do heap ou adicione mais memória ao sistema.
Se ocorrer paginação, reduza o tamanho do heap ou adicione mais memória ao sistema.
Quando todas as execuções concluírem, compare as seguintes estatísticas:- Número de chamadas de coleta de lixo
- Duração média de uma única chamada de coleta de lixo
- Proporção entre o comprimento de uma única chamada de coleta de lixo e o tempo média entre as chamadas
Se o aplicativo não estiver utilizando excessivamente objetos e não tiver fugas de memória, o estado de utilização estável de memória será alcançado. A coleta de lixo também ocorre menos frequentemente e por uma duração curta.
Se o espaço livre do heap for estabelecido como 85 por cento ou mais, considere diminuir os valores de tamanho máximo do heap porque o servidor de aplicativos e o aplicativo estão usando pouco a memória alocada para o heap.
Se tiver servidores configurados para executar no modo de 64 bits, você pode especificar um tamanho de heap JVM máximo para os servidores significativamente maiores que a configuração padrão. Por exemplo, é possível especificar um tamanho máximo de heap inicial de 1844 MB para o controlador e o servidor, se o servidor estiver configurado para executar em modo de 64 bits.
- Clique em Aplicar.
- Clique em Salvar para salvar as alterações na configuração principal.
- Pare e inicie o servidor de aplicativos novamente.
Você também pode usar os seguintes parâmetros de linha de comandos para ajustar essas configurações. Esses parâmetros se aplicam a todas as JVMs suportadas e são utilizadas para ajustar os tamanhos de heap mínimo e máximo para cada servidor de aplicativo ou instância de servidor de aplicativo.
- -Xms
Esse parâmetro controla o tamanho inicial do heap Java. O ajuste desse parâmetro reduz o gasto adicional de coleta de lixo, o que melhora o rendimento de processamento e o tempo de resposta do servidor. Para alguns aplicativos, a configuração padrão para essa opção pode ser muito longa, o que causa um alto número de coletas de lixo secundárias.
Informações Valor Padrão 50 MB Recomendado Específico de carga de trabalho, mas superior ao padrão. Uso A especificação de -Xms256m configura o tamanho de heap inicial para 256 MB. - -Xmx
Esse parâmetro controla o tamanho máximo do heap Java. Aumentar esse parâmetro aumenta a memória disponível para o servidor de aplicativos e reduz a frequência da coleta de lixo. Aumentar essa configuração pode aprimorar o tempo de resposta do servidor e o rendimento do processamento. No entanto, aumentar essa configuração também aumenta a duração de uma coleta de lixo quando ela ocorre. Esta configuração nunca deve ser aumentada acima da memória do sistema disponível para a instância do servidor de aplicativos. Aumentar a configuração acima da memória do sistema pode causar paginação do sistema e um decréscimo significativo sobre o desempenho.
Informações Valor Padrão Por padrão, a JVM calcula dinamicamente o tamanho da heap Java baseado na memória disponível no sistema. Recomendado Carga de trabalho específica, mas superior ao valor-padrão, dependendo da quantidade de memória física disponível. Uso A especificação de -Xmx512m configura o tamanho de heap máximo para 512 MB. Evitar Problemas: Especifique um valor para o parâmetro -Xmx para reduzir possíveis problemas de falta de memória.gotcha
-Xlp
Use esse parâmetro com a IBM virtual machine para Java para alocar a heap ao usar páginas grandes, como páginas de 16 MB. Antes de especificar esse parâmetro, verifique se seu sistema operacional está configurado para suportar páginas grandes. A utilização de páginas grandes pode reduzir a sobrecarga da CPU necessária para rastrear a memória de heap e também pode permitir a criação de um heap maior.
Padrão 64 KB se você estiver usando o Java 8 –Xlp64k
Este parâmetro pode ser usado para alocar o heap usando páginas de tamanho médio, como 64 KB. O uso desse tamanho de página de memória virtual para a memória requerida por um aplicativo pode melhorar o desempenho e o rendimento de processamento do aplicativo devido às eficiências do hardware que estão associadas a uma página de tamanho maior.
i5/OS e AIX fornecem rico suporte em páginas de 64 KB, porque páginas de 64 KB destinam-se a serem páginas de propósito geral. As páginas de 64 KB são fáceis de ativar e os aplicativos podem receber benefícios de desempenho quando as páginas de 64 KB são usados. Essa configuração pode ser alterada sem alterar a configuração do sistema operacional. No entanto, é recomendado que você execute seus servidores de aplicativos em um conjunto de armazenamentos separado se usar páginas de 64 KB.
Recomendado Use o tamanho de página de 64 KB sempre que possível. Sistemas i5/OS POWER5+ e i5/OS Versão 6, Liberação 1, suportam um tamanho de página de 64 KB.
Sistemas POWER5+ e AIX 5L Versão 5.3 com Pacote de Manutenção Recomendado 5300-04 suportam um tamanho de página de 64 KB quando estão executando o kernel de 64 bits.
–Xlp4k
Este parâmetro pode ser usado para alocar o heap usando páginas de 4 KB. Usar este tamanho de página de memória virtual para a memória que um aplicativo requer, em vez de 64 KB, pode impactar negativamente o desempenho e o rendimento do aplicativo devido a ineficiências de hardware que estão associadas a um tamanho de página menor.
A configuração de alocação de heap Java pode ser mudada sem mudar a configuração do sistema operacional. No entanto, é recomendado que você execute seus servidores de aplicativos em um conjunto de armazenamentos separado se usar páginas de 64 KB.
Recomendado Use -Xlp64k em vez de -Xlp4k sempre que possível.
- Ajuste a memória Java. Aplicativos corporativos escritos na linguagem Java envolvem relacionamentos complexos entre objetos e utilizam grandes números de objetos. Embora a linguagem Java gerencie automaticamente a memória associada a ciclos de vida de objetos, é importante compreender os padrões de uso do aplicativo para objetos. Verifique, especificamente, se existem as seguintes condições:
- O aplicativo não está utilizando excessivamente objetos.
- Que o aplicativo não está vazando objetos
- Os parâmetros de heap Java estão configurados apropriadamente para tratar de um determinado padrão de uso de objetos
- Verifique a utilização excessiva de objetos.
É possível revisar os contadores para o tempo de execução do JVM, que estão incluídos em relatórios do Tivoli Performance Viewer, para determinar se um aplicativo está sobreutilizando objetos. Você dever especificar a opção da linha de comandos -XrunpmiJvmtiProfiler, como também o nível máximo do módulo JVM, para ativar a interface do gerenciador de perfis da Java virtual machine, a JVMTI e os contadores.
O resultado ideal para o tempo médio entre coletas de lixo é de pelo menos cinco a seis vezes a duração média de uma única coleta de lixo. Se você não chegar a esse número, o aplicativo está gastando mais de 15 por cento de seu tempo na coleta de lixo.
É possível verificar se o aplicativo está utilizando em excesso objetos pela observação dos contadores do tempo de execução da JVM. Você dever especificar a opção da linha de comandos -XrunpmiJvmtiProfiler, como também o nível máximo do módulo JVM, para ativar a interface do gerenciador de perfis da Java virtual machine, a JVMTI e os contadores. O resultado ideal para o tempo médio entre coletas de lixo é de pelo menos cinco a seis vezes a duração média de uma única coleta de lixo. Se você não chegar a esse número, o aplicativo está gastando mais de 15 por cento de seu tempo na coleta de lixo.
Se as informações indicarem um gargalo da coleta de lixo, há duas maneiras de limpá-lo. A maneira mais eficiente de otimizar o aplicativo é implementar caches e conjuntos de objetos. Utilize o gerenciador de perfis Java para determinar quais objetos devem ser destinados. Se você não puder otimizar o aplicativo, tente incluir memória, processadores e clones. A memória adicional permite que cada clone mantenha um tamanho de heap considerável. Os processadores adicionais permitem que os clones sejam executados em paralelo.
- Teste de fugas de memória.
As fugas de memória na linguagem Java são um perigoso contribuinte para gargalos de coleta de lixo. As fugas de memória são mais prejudiciais que o uso excessivo de memória, porque uma fuga de memória acaba levando a instabilidade no sistema. No decorrer do tempo, a coleta de lixo ocorre com mais frequência até que o heap se esgote e o código Java falhe com uma exceção fatal de falta de memória. As fugas de memória ocorrem quando um objeto não utilizado tem referências que nunca são liberadas. As fugas de memória ocorrem com mais freqüência em classes de coleção, tais como Hashtable, porque a tabela sempre tem uma referência ao objeto, mesmo depois que as referências reais são excluídas.
Uma carga de trabalho elevada muitas vezes faz com que os aplicativos falhem imediatamente após a implementação no ambiente de produção. Se um aplicativo tiver fugas de memória, uma alta carga de trabalho poderá acelerar a ampliação da fuga e causar falhas de alocação de memória.
O objetivo do teste de fuga de memória é amplificar os números. As fugas de memória são medidas em função da quantidade de bytes ou de kilobytes que não pode ser lixo coletado. A tarefa delicada é diferenciar entre essas quantidades e os tamanhos esperados de memória útil e não utilizável. Essa tarefa é alcançada mais facilmente se os números forem amplificados, resultando em intervalos maiores e identificação mais fácil das inconsistências. A lista a seguir fornece insight sobre como interpretar os resultados de seu teste de fuga de memória:- Teste de longa duração
Os problemas de fuga de memória podem se manifestar apenas depois de um período de tempo, portanto, as fugas de memória são localizadas facilmente durante testes de longa duração. Testes de curta execução podem fornecer indicações inválidas de onde estão acontecendo as fugas de memória. Às vezes é difícil saber quando uma fuga de memória está ocorrendo na linguagem Java, especialmente quando o uso de memória aparentemente aumentou de maneira abrupta ou uniforme em um determinado período. O motivo porque é difícil detectar uma fuga de memória é que esses tipos de aumentos podem ser válidos ou podem ser a intenção do desenvolvedor. Você pode aprender a diferenciar entre o retardo no uso de objetos e os objetos completamente não utilizados executando os aplicativos por um período de tempo maior. Os testes de aplicativos de longa duração dão mais confiança sobre se a utilização retardada de objetos está realmente ocorrendo.
- Teste repetitivo
Em muitos cacos, os problemas de fuga de memória ocorrem por repetições sucessivas da mesma etapa de teste. O objetivo do teste de fuga de memória é estabelecer um grande intervalo entre memória não utilizável e utilizada em função de seus tamanhos relativos. Pela repetição sucessiva do mesmo cenário por muitas vezes, o intervalo é multiplicado de uma maneira muito progressiva. Esse teste ajuda se o número de fugas causadas pela execução de um caso de teste for tão pequeno que dificilmente possa ser notado em uma execução.
Os testes repetitivos podem ser utilizados no nível do sistema ou no nível do módulo. A vantagem com o teste modular é melhor controle. Quando um módulo é projetado para manter o módulo privado sem criar efeitos colaterais externos tais como uso de memória, o teste de fugas de memória é mais fácil. Primeiro, o uso de memória antes da execução do módulo é registrado. Em seguida, um conjunto fixo de casos de teste é executado repetidamente. No final da execução do teste, o uso de memória atual é registrado e verificado quanto a alterações significativas. Lembre-se, a coleta de lixo deve ser sugerida ao registrar o uso real de memória pela inserção de System.gc() no módulo em que você deseja que a coleta de lixo ocorra, ou utilizando uma ferramenta de análise de perfil, para forçar que o evento ocorra.
- Teste de concorrência
Alguns problemas de fuga de memória podem ocorrer apenas quando existem vários encadeamentos em execução no aplicativo. Infelizmente, os pontos de sincronização são muito suscetíveis a fugas de memória devido à complicação adicional na lógica do programa. Uma programação negligente pode levar a referências mantidas ou não liberadas. O incidente de fugas de memória é muitas vezes facilitado ou acelerado pelo aumento de simultaneidade no sistema. A maneira mais comum de aumentar a simultaneidade é aumentar o número de clientes no driver de teste.
Considere os seguintes pontos ao escolher que casos de teste devem ser utilizados para testar fugas de memória:- Uma boa etapa de teste exercita áreas do aplicativo onde objetos são criados. Na maioria das vezes, o conhecimento do aplicativo é requerido. Uma descrição do cenário pode sugerir a criação de espaços de dados, tais como adicionar um novo registro, criar uma sessão HTTP, executar uma transação e pesquisar um registro.
- Examine áreas onde coleções de objetos são utilizadas. Tipicamente, fugas de memória são compostas de objetos dentro da mesma classe. Além disso, as classes de coleção tais como Vector e Hashtable são lugares comuns onde as referências a objetos são implicitamente armazenadas através da chamada de métodos de inserção correspondentes. Por exemplo, o método get de um objeto Hashtable não remove sua referência ao objeto recuperado.
É possível utilizar o Tivoli Performance Viewer para ajudar a encontrar fugas de memória.
Para resultados ideais, repita experimentos com duração aumentada, como 1.000, 2.000 e 4.000 pedidos de página. O gráfico da memória utilizada do Tivoli Performance Viewer deve ter uma forma de dente de serra. Cada parte do gráfico corresponde a uma coleta de lixo. Ocorrerá uma fuga de memória se uma das condições a seguir aparecer no gráfico:
- A quantidade de memória utilizada imediatamente depois de cada coleta de lixo aumentar significativamente. Quando essa condição ocorre, o padrão de dente de serra fica mais parecido com uma escadaria.
- O padrão irregular tem uma forma irregular.
- A diferença entre o número de objetos alocados e o número de objetos liberados aumenta com o tempo.
O consumo de heap que indica uma possível fuga durante os períodos em que o servidor de aplicativos está consistentemente próximo de 100 por cento de utilização de CPU, mas desaparece quando a carga de trabalho fica mais leve ou quase inativa, é uma indicação de fragmentação do heap. A fragmentação do heap pode ocorrer quando a JVM pode liberar objetos suficientes para satisfazer a pedidos de alocação de memória durante os ciclos de coleta de lixo, mas a JVM não tem tempo para compactar pequenas áreas de memória livre no heap para espaços contíguos maiores.
Outra forma de fragmentação de heap ocorre quando os objetos com menos de 512 bytes são liberados. Os objetos são liberados, mas o armazenamento não é recuperado, resultando em fragmentação de memória até ocorrer uma compactação do heap.
A fragmentação do heap pode ser reduzida forçando-se as compactações. Entretanto, existe uma perda de desempenho quando se força as compactações. Utilize o comando Java -X para ver a lista de opções de memória.
- Teste de longa duração
- Ajuste a coleta de lixo
A JVM usa um coletor de lixo paralelo para explorar totalmente um SMP durante a maioria dos ciclos de coleta de lixo.
Examinar a coleta de lixo de Java ajuda a compreender como o aplicativo está utilizando a memória. A coleta de lixo é um ponto forte de Java. Retirando a carga do gerenciamento de memória do criador do aplicativo, os aplicativos Java são mais robustos que os aplicativos escritos em linguagens que não fornecem coleta de lixo. Esta robustez é aplicada desde que o aplicativo não esteja utilizando objetos em excesso. Normalmente a coleta de lixo consome de 5 a 20 por centro do tempo de execução total de um aplicativo em perfeito funcionamento. Se não for gerenciada, a coleta de lixo será um dos maiores gargalos de um aplicativo.
O monitoramento da coleta de lixo enquanto uma carga de trabalho fixa está em execução fornece um insight sobre se o aplicativo está usando objetos em excesso. A coleta de lixo pode até mesmo detectar a presença de fugas de memória.
É possível usar configurações JVM para configurar o tipo e o comportamento da coleta de lixo. Quando a JVM não pode alocar um objeto do heap atual devido à falta de espaço contíguo, o coletor de lixo é chamado para reivindicar memória de objetos Java que não estão mais sendo utilizados. Cada fornecedor JVM fornece políticas de coletor de lixo exclusivas e parâmetros de ajuste.
Você pode usar a configuração Coleta de Lixo Detalhada no console administrativo para ativar o monitoramento da coleta de lixo. A saída dessa configuração inclui estatísticas de coleta de lixo da classe. O formato do relatório gerado não é padronizado entre as diferentes JVMs ou níveis de releases.
Para ajustar suas configurações de coleta de lixo JVM:
- No console administrativo, clique em Servidores>Tipos de Servidor>Servidores de Aplicativos do WebSphere> server_name.
Na seção Infraestrutura do Servidor, clique em Gerenciamento Java e de Processo > Definição de Processo > Java Virtual Machine
Insira a opção –X que deseja alterar no campo Argumentos Genéricos da JVM.
Na seção Infraestrutura do Servidor, clique em Gerenciamento Java e Processos > Definição de Processo > Servidor.
Sob Propriedades Adicionais, clique em Entradas do Ambiente.
Inclua ou atualize a entrada do ambiente para IBM_JAVA_OPTIONS da seguinte forma:
- Se você visualizar uma entrada de ambiente existente denominada IBM_JAVA_OPTIONS, edite-a para anexar a opção –X de Java que deseja incluir no valor existente.
- Caso contrário, clique em Novo para criar uma nova entrada do ambiente.
Preencha os valores a seguir em seus respectivos campos do formulário:
Informações Valor Nome: IBM_JAVA_OPTIONS Valor: A opção –X de Java que deseja incluir Descrição: Uma descrição desta opção
Esse procedimento atualiza o arquivo was.env no diretório de configuração do WebSphere Application Server. A mudança aplicará as configurações a todas as regiões do servidor, controle e auxiliares.
- Clique em Aplicar.
- Clique em Salvar para salvar suas mudanças na configuração principal.
- Pare e inicie o servidor de aplicativos novamente.
A lista a seguir descreve as opções –X para os diferentes coletores de lixo JVM.
- O coletor de lixo da IBM virtual machine para Java.
- Um guia completo para a implementação IBM do coletor de lixo Java é fornecido na publicação Guia do Usuário do IBM SDK, Java Technology Edition, Versão 8.
Utilize a opção Java -X para visualizar uma lista de opções de memória.
- -XgcpolicyA IBM virtual machine para Java fornece quatro políticas para a coleta de lixo. Cada política fornece benefícios exclusivos.Nota: Enquanto cada política fornece benefícios exclusivos, para o WebSphere Application Server Versão 8.0 e mais recentes, gencon é a política de coleta de lixo padrão. As versões anteriores do servidor de aplicativos especificam que optthruput é a política de coleta de lixo padrão.
- gencon é a política padrão. Essa política funciona com o coletor de lixo de geração. O esquema referente à geração tenta alcançar alto rendimento do processamento juntamente com tempos de pausa da coleta de lixo reduzidos. Para realizar esse objetivo, o heap é dividido em segmentos novos e antigos. Os objetos de duração longa são promovidos ao espaço antigo, enquanto os objetos de duração curta são coletados no lixo rapidamente no novo espaço. A política gencon beneficia significativamente muitos aplicativos. Entretanto, ela não é adequada para todos os aplicativos e, normalmente, é mais difícil de ajustar.
- optthruput fornece alto rendimento, mas com períodos de pausa da coleta de lixo mais longos. Durante uma coleta de lixo, todos os encadeamentos do aplicativo são parados para marcação, varredura e compactação, quando a compactação for necessária. A política gencon é suficiente para a maioria dos aplicativos.
- optavgpause é a política que reduz o tempo de pausa da coleta de lixo executando as fases marca e tempo de acesso da coleta de lixo enquanto um aplicativo está em execução. Essa política causa um pequeno impacto no desempenho do rendimento de processamento geral.
- subpool é uma política que aumenta o desempenho em sistemas multiprocessadores que costumam usar mais de 8 processadores. Essa política está disponível somente em processadores IBM System i System p e System z. A política de subconjunto é semelhante à política gencon, exceto que o heap é dividido em subconjuntos que fornecem escalabilidade aprimorada para alocação de objetos.
Informações Valor Padrão gencon Recomendado gencon Uso Especificar Xgcpolicy:gencon configura a política de coleta de lixo para gencon. Configurar gcpolicy para gencon desativa a marca simultânea. Você deverá ter os resultados de rendimento ideais quando usar a política gencon, a menos que experimente tempos de resposta do aplicativo irregulares, que é uma indicação de pode haver problemas no tempo de pausa
Configurar gcpolicy como optavgpause ativa a marcação simultânea com seus valores padrão. Essa configuração reduz os tempos de resposta instáveis do aplicativo que a coleta de lixo normal causa. No entanto, esta opção pode reduzir o rendimento do processamento geral.
- -Xnoclassgc
Por padrão, a JVM descarrega uma classe da memória sempre que não tenham sido deixadas instâncias ativas dessa classe. A sobrecarga de carregamento e descarregamento da mesma classe várias vezes pode reduzir o desempenho.
Evitar Problemas: Você pode usar o argumento -Xnoclassgc para desativar a coleta de lixo da classe. Entretanto, o impacto no desempenho da coleta de lixo de classe normalmente é mínimo, e a desativação da coleta de lixo de classe em um sistema baseado em Java Platform, Enterprise Edition (Java EE), com seu uso intenso de carregadores de classes de aplicativo, pode criar efetivamente uma fuga de memória dos dados da classe e fazer a JVM emitir uma Exceção de Falta de Memória.
Se você usar esta opção, quando reimplementar um aplicativo, sempre será necessário reiniciar o servidor de aplicativos para limpar as classes e dados estáticos da versão anterior do aplicativo.
gotchaInformações Valor Padrão A coleta de lixo de classe está ativada. Recomendado Não desative a coleta de lixo de classe.
Uso Especifique Xnoclassgc para desativar a coleta de lixo da classe.
- -Xgcpolicy
- Ativar o armazenamento em cache do nome do host local Por padrão no IBM SDK
para Java, o método estático java/net/InetAddress.getLocalHost não armazena em cache seu resultado. Esse método é usado em todo o WebSphere Application
Server, mas particularmente em agentes administrativos como o gerenciador de implementação e o agente do nó. Se o endereço do host local de um processonão for alterado enquanto é executado, ele é avisado para usar um cache integrado para a consulta do host local configurando a propriedade do sistema com.ibm.cacheLocalHost para o valor true. Consulte o tópico de propriedades customizadas do Java virtual machine no centro de informações para obter instruções sobre a configuração de propriedades customizadas JVM nos vários tipos de processos.
Evitar Problemas: O endereço para servidores configurado usando a mudança do DHCP ao longo do tempo. Não configure esta propriedade, a menos que esteja usando endereços IP estaticamente designados para o seu servidor.gotcha
Informações Valor Padrão com.ibm.cacheLocalHost = false Recomendado com.ibm.cacheLocalHost = true (consulte a descrição) Uso Especificar -Dcom.ibm.cacheLocalHost=true ativa o cache getLocalHost - Ative o compartilhamento de classe num cache.
A opção de classes de compartilhamento permite que você compartilhe classes em um cache. O compartilhamento de classes em um cache pode aprimorar o tempo de inicialização e reduzir a necessidade de memória. Processos, como servidores de aplicativos, agentes de nó e gerenciadores de implementação, podem utilizar a opção de compartilhar classes.
Esta opção fica ativada por padrão no servidor de aplicativos. Para limpar o cache, chame o utilitário app_server_root/bin/clearClassCache ou pare e reinicie o servidor de aplicativos.
Se você usar essa opção, deve limpar o cache quando o processo não estiver em utilização. Para limpar o cache, chame o utilitário app_server_root/bin/clearClassCache.bat/sh ou pare o processo e, em seguida, reinicie o processo.
Nota: Ao usar clearclasscache, para limpar o cache inteiro, você deve parar todas as JVMs conectadas.Se você precisa desativar a opção de compartilhar classes para um processo, especifique o argumento JVM genérico -Xshareclasses:none para esse processo:
- No console administrativo, clique em Servidores>Tipos de Servidor>Servidores de Aplicativos do WebSphere> server_name.
Na seção Infraestrutura do Servidor, clique em Gerenciamento Java e de Processo > Definição de Processo > Java Virtual Machine
Na seção Infraestrutura do Servidor, clique em Gerenciamento Java e de Processo > Definição de Processo
Selecione Controle ou Servidor e selecione Java Virtual Machine.
- Insira -Xshareclasses:none no campo Argumentos Genéricos da JVM.
- Clique em OK.
- Clique em Salvar para salvar as alterações na configuração principal.
- Pare e reinicie o servidor de aplicativos.
Informações Valor Padrão A opção Compartilhar classes em um cache está desativada. Recomendado Deixe a opção Compartilhar Classe em um Cache ativada. Uso A especificação de -Xshareclasses:none desativa as classes de compartilhamento em uma opção do cache. Ative as referências compactadas nos ambientes de 64 bits.
É possível ativar referências compactadas em ambientes de 64 bits, como AIX 64, Linux PPC 64, zLinux 64, e Microsoft Windows AMD64, Linux AMD64.
Também é possível ativar referências compactadas nos ambientes IBM i de 64 bits, como IBM i Versão 6.1.
A opção de referências compactadas da implementação do IBM do Java SE Runtime Environment (JRE) Versão 6.0 de 64 bits permite que você limite todas as referências de memória para o tamanho de 32 bits. Normalmente, as JVMs de 64 bits usam mais espaço de heap do que as JVMs de 32 bits, pois usam referências de memória de 64 bits para endereçar memória. The heap that is addressable by the 64-bit reference is orders of magnitude larger than the 32-bit heap, but in the real world, a heap that requires all 64-bits for addressing is typically not required. A compactação das referências reduz o tamanho dos endereços e faz uso mais eficiente do heap. A compactação dessas referências também melhora o cache do processador e a utilização do barramento, melhorando assim o desempenho.
Evitar Problemas: gotcha
O recurso de referências compactadas não é suportado na:- HP-UX 64-bit JVM
- iSeries Classic 64-bit JVM
Para ativar uma JVM de 64 bits para se executada no modo de referências compactadas, é necessário especificar um novo ambiente na configuração do WebSphereApplication Server. No console administrativo:
- Clique em: Servidores > Tipos de Servidor > Servidores de Aplicativos do WebSphere > server_name.
- Clique na guia Configuração. Em Infraestrutura de Servidor, clique em Java e gerenciamento de processo > ProcessDefinition > servidor.
- Sob Propriedades Adicionais, clique em Entradas do Ambiente.Inclua ou atualize a entrada do ambiente para IBM_JAVA_OPTIONS como segue:
- Se você visualizar uma entrada de ambiente existente chamada IBM_JAVA_OPTIONS, edite-a para anexar a opção Java –Xcompressedrefs no valor existente.
- Caso contrário, clique em Novo para criar uma nova entrada do ambiente. Preencha os valores a seguir em seus respectivos campos do formulário:
Informações Valor Nome: IBM_JAVA_OPTIONS Valor: -Xcompressedrefs Descrição: Ativar modo de referências compactadas de 64 bits
Esse procedimento atualiza o arquivo was.env no diretório de configuração do WebSphere Application Server. A mudança aplicará as configurações a todas as regiões do servidor, controle e auxiliares.
Evitar Problemas: Ao fornecer Xcompressedrefs como um argumento de JVM genérico, o WebSphereApplication Server falhará ao iniciar devido a um erro de opção Java não suportada. Se o aplicativo exigir um heap Java com mais de 30 GB, então o modo padrão de 64 bits deve ser utilizadogotcha
O produto ativa automaticamente a compactação de ponteiro nas plataformas suportadas pelo padrão se o tamanho de heap (controlado pelo parâmetro -Xmx) estiver configurado abaixo de um determinado tamanho de heap (em torno de 25 GB, dependendo da plataforma); isso será padronizado como referências não compactadas. O usuário pode substituir esses padrões usando as opções de linha de comandos a seguir.
Nota: O WebSphere Application Server for z/OS não ativa automaticamente a compactação do apontador. Recomenda-se que os usuários ativem manualmente a compactação do ponteiro usando as opções da linha de comandos.
Nota: Para o Java 8 SR2 FP10 ou para o z/OS Java 8 SR3, a opção -Xcompressedrefs é ativada, por padrão, até 57 GB e pode ser usada com valores superiores, dependendo da plataforma.As opções de linha de comandos a seguir controlam o recurso de referências compactadas:- -Xcompressedrefs
- Essa opção da linha de comandos ativa o recurso de referências compactadas. Quando a JVM é ativada com essa opção da linha de comandos, ela usa referências de memória de 32 bits para endereçar o heap. Esse recurso pode ser usado até um determinado tamanho de heap (em torno de 29 GB, dependendo da plataforma), controlado pelo parâmetro -Xmx.
- -Xnocompressedrefs
- Essas opções da linha de comandos desativam explicitamente o recurso de referências compactadas. Quando a JVM é ativada com essa opção da linha de comandos, ela usa referências de memória de 64 bits para endereçar o heap. Essa opção pode ser usada pelo usuário para substituir a ativação padrão de compactação de ponteiro, caso seja necessário.
- Ajuste o processo de atualização de configuração para a configuração
de uma célula grande. Em uma configuração de célula grande, você pode precisar determinar se o desempenho da atualização de configuração ou a verificação de consistência é mais importante. O gerenciador de implementação mantém um repositório de configuração principal para toda a célula. Por padrão, quando a configuração é alterada, o produto compara a configuração na área de trabalho com o repositório principal para manter a consistência da área de trabalho. Porém, o processo de verificação de consistência pode causar uma aumento na quantidade de tempo para salvar uma mudança de configuração ou para implementar um grande número de aplicativos. Os seguintes fatores influenciam quanto tempo é necessário:
- Quanto mais servidores de aplicativos ou clusters são definidos em uma célula, mais tempo se leva para salvar uma mudança na configuração.
- Quanto mais aplicativos são implementados em uma célula, mais tempo se leva para salvar uma mudança na configuração.
Se a quantidade de tempo necessária para fazer uma mudança de configuração não for satisfatória, é possível incluir a propriedade customizada config_consistency_check nas configurações da JVM e definir o valor dessa propriedade como false.- No console administrativo, clique em Administração do sistema > Gerenciador de implementação.
- Na Infraestrutura do Servidor, selecione Java e Gerenciamento de Processo e, em seguida, clique em Definição do Processo.
- Em Propriedades Adicionais, clique em Java Virtual Machine > Propriedades Customizadas > Novo.
- Digite config_consistency_check no campo Nome e false no campo Valor.
- Clique em OK e depois salve essas mudanças para a configuração principal.
- Inicie novamente o servidor.
Configurações suportadas: A propriedade customizada config_consistency_check afeta apenas o processo do gerenciador de implementação. Ela não afeta outros processos incluindo o agente do nó e processos do servidor de aplicativos. A verificação de consistência não é executada nesses processos. Entretanto, dentro dos arquivos SystemOut.log para esses processos, você poderá ver uma nota de que a verificação de consistência está desativada. Para esses processos do gerenciador de não implementação, você poderá ignorar essa mensagem.sptcfg
Se estiver usando o comando wsadmin wsadmin -conntype none no modo local, você deve configurar a propriedade config_consistency_check como false antes de emitir esse comando.
O que Fazer Depois


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tprf_tunejvm_v61
Nome do arquivo: tprf_tunejvm_v61.html