Utilize esta página para visualizar e alterar as definições de configuração da Java Virtual Machine (JVM) de um processo para um servidor de aplicativos.
Para visualizar esta página do console administrativo, conecte-se ao console administrativo e navegue para o painel Java Virtual Machine.
Para o IBM i e plataformas distribuídas,clique em Servidores > Tipos de Servidores > Servidores de Aplicativos do WebSphere > server_name. Em seguida, na seção Infraestrutura do Servidor, clique em Gerenciamento de Java e Processos > Definição de Processo > Java virtual machine.
Servidor de Aplicativos | Clique em Servidores>Tipos de Servidor>Servidores de Aplicativos do WebSphere> server_name. Em seguida, na seção Infraestrutura do Servidor, clique em Gerenciamento de Java e Processos > Definição de Processo > Controle > Java virtual machine. |
Gerenciador de Implementação | Clique em Administração de Sistema > Gerenciador de Implementação. Em seguida, na seção Infraestrutura do Servidor, clique em Gerenciamento de Java e Processos > Definição de Processo > Controle > Java virtual machine. |
Agente do nó | Clique em Administração do Sistema > Agente do Nó > node_agent. Em seguida, na seção Infraestrutura do Servidor, clique em Gerenciamento de Java e Processos > Definição de Processo > Java virtual machine. |
Servidor de Aplicativos | Servidores > Tipos de Servidores > Servidores de Aplicativos do WebSphere > server_name. Em seguida, na seção Infraestrutura do Servidor, clique em Gerenciamento de Java e Processos > Definição de Processo > Java virtual machine. |
Gerenciador de Implementação | Administração do Sistema > Gerenciador de Implementação. Em seguida, na seção Infraestrutura do Servidor, clique em Gerenciamento de Java e Processos > Definição de Processo > Java virtual machine. |
Agente do nó | Administração do Sistema > Agente do Nó > node_agent. Em seguida, na seção Infraestrutura do Servidor, clique em Gerenciamento de Java e Processos > Definição de Processo > Java virtual machine. |
Especifica o caminho de classe padrão no qual o código da Java Virtual Machine procura por classes.
Se você precisar incluir um caminho de classe neste campo, insira cada entrada do caminho de classe em uma linha de tabela separada. Você não precisa incluir dois pontos ou um ponto-e-vírgula no final de cada entrada.
Tipo de Dados | Cadeia |
Especifica as classes e recursos de inicialização para o código da JVM. Esta opção está disponível somente para instruções da JVM que suportam classes e recursos de inicialização.
Se você precisar incluir um caminho de classe nesse campo, digite cada entrada do caminho de classe em uma linha de tabela. Não é necessário incluir os dois pontos ou ponto-e-vírgula no final de cada entrada.
Se você precisar incluir vários caminhos de classe neste campo, poderá utilizar dois pontos (:) ou ponto-e-vírgula (;), dependendo do sistema operacional no qual a JVM reside, para separar esses caminhos de classe.
Se você precisar incluir vários caminhos de classe neste campo, poderá utilizar dois pontos (:) ou ponto-e-vírgula (;), dependendo do sistema operacional no qual o nó reside, para separar esses caminhos de classe.
Especifica se deve utilizar a saída de depuração detalhada para carregamento de classe. O padrão é não ativar o carregamento de classe detalhada.
Se o carregamento de classe detalhada for ativado, a saída de depuração
será enviada para um dos logs de processo nativos.
Tipo de Dados | Booleano |
Padrão | falso |
Especifica se deve utilizar a saída de depuração detalhada para coleta de lixo. O padrão é não ativar a coleta de lixo detalhada.
Se a coleta de lixo detalhada for ativada, a saída de depuração será
enviada para um dos logs de processo nativos.
Tipo de Dados | Booleano |
Padrão | falso |
Quando esse campo está ativado, um relatório é gravado no fluxo de saída cada vez que o coletor de lixo é executado. Esse relatório deve fornecer uma indicação de como o processo de coleta de lixo Java está funcionando.
83.29/3724.32 * 100 = 2.236 por cento
Se você estiver gastando mais de 5 por cento de seu tempo na coleta de lixo e se ela estiver ocorrendo com freqüência, pode ser necessário aumentar o tamanho de heap Java.
Para determinar se o heap alocado está aumentando, consulte a porcentagem do heap que permanece não-alocada após cada ciclo de coleta de lixo e verifique se a porcentagem não continua sendo recusada. Se a porcentagem do espaço livre continuar sendo recusada, você está passando por um crescimento gradual no tamanho do heap da coleta de lixo para coleta de lixo. Esta situação pode indicar que seu aplicativo possui uma fuga de memória.
Na plataforma z/OS, também é possível emitir o comando o console MVS,
modify display, jvmheap, para exibir informações de heap da JVM. Além disso, você pode verificar a atividade do servidor e registros de intervalo do SMF. O
tamanho de heap da JVM também é disponibilizado para PMI e pode ser monitorado utilizando-se o Tivoli Performance
Viewer.
Especifica se deve utilizar a saída de depuração detalhada para chamada de método nativo. O padrão é não ativar a atividade Java Native Interface (JNI) detalhada.
Tipo de Dados | Booleano |
Padrão | falso |
Especifica o tamanho de heap inicial em megabytes para o código de JVM. Se esse campo for deixado em branco, o valor padrão será utilizado.
Para z/OS, o tamanho de heap inicial padrão para o controlador
é 48 MB e o tamanho de heap inicial padrão para o servant é 128 MB. Esses valores padrão se aplicam a configurações de 31 bits e 64 bits.
Para plataformas IBM i e distribuídas, o tamanho de heap
inicial padrão é 50 MB.
O aumento dessa configuração pode aprimorar a inicialização. O número de ocorrências de coleta de lixo é reduzido e um ganho de 10 por cento no desempenho é atingido.
O aumento do tamanho do heap Java continua melhorando o rendimento de processamento até que o heap fique muito grande para residir na memória física. Se o tamanho de heap exceder a memória física disponível e ocorrer paginação, haverá uma redução notável no desempenho.
Especifica o tamanho de heap inicial disponível para o código de JVM, em megabytes. Se esse campo for deixado em branco, o valor padrão será utilizado.
O tamanho de heap máximo padrão é 256 MB. Este valor padrão aplica-se às configurações de 31 bits e 64 bits.
Aumentar a configuração do tamanho de heap máximo pode aprimorar a inicialização. Quando você aumenta o tamanho de heap máximo, reduz o número de ocorrências de coleta de lixo com um ganho de 10 por cento no desempenho.
Aumentar essa configuração normalmente melhora o rendimento do processamento até que o heap fique muito grande para residir na memória física. Se o tamanho de heap exceder a memória física disponível e ocorrer paginação, haverá uma redução notável no desempenho. Portanto, é importante que o valor especificado para essa propriedade permita que o heap fique contido dentro da memória física.
Para impedir a paginação, especifique um valor para esta propriedade que
permite um mínimo de 256 MB de memória física para cada processador e 512 MB
de memória física para cada servidor de aplicativos. Se a utilização do processador estiver baixa
por causa da paginação, aumente a memória disponível, se possível, em vez de aumentar o
tamanho máximo de heap. Aumentar o tamanho máximo de heap pode diminuir o
desempenho em vez de melhorá-lo.
Para IBM i, quando essa propriedade é configurada como 0,
o coletor de lixo só é executando quando o seu limite é atingido. Quando um valor diferente de 0 for especificado, o
coletor de lixo será executado sempre que o tamanho de heap atingir o tamanho
máximo especificado. No entanto, diferente de um coletor de lixo normal,
se o tamanho máximo for alcançado, todos os encadeamentos de aplicativos
devem aguardar até que o processo de coleta de lixo seja concluído antes que possam continuar a execução. Esta situação pode provocar tempos de pausa indesejáveis. Portanto, utilize o
tamanho máximo de heap como uma rede de segurança para tratar de ocorrências de
crescimento de heap inesperado e para assegurar-se de que o heap não fique
maior do que a memória disponível. Em circunstâncias normais, o tamanho máximo de heap
especificado nunca é alcançado.
Especifica se o suporte ao gerenciador de perfis HProf deve ser utilizado. Para utilizar outro perfil, especifique as configurações do gerenciador de perfis customizadas utilizando a configuração Argumentos HProf. O padrão é não ativar o suporte ao criador de perfil HProf.
Se você configurar a propriedade Run HProf para true, deve especificar argumentos do gerenciador de perfis de linha de comandos como valores para a propriedade Argumentos HProf.
Tipo de Dados | Booleano |
Padrão | falso |
Especifica argumentos do criador de perfil da linha de comandos a serem transmitidos para o código de JVM que inicia o processo do servidor de aplicativos. É possível especificar argumentos quando o suporte ao criador de perfil HProf está ativado.
Os argumentos HProf são necessários apenas se a propriedade Executar HProf for configurada para true.
Especifica se a JVM deve ser executada no modo de depuração. O padrão é não ativar o suporte do modo de depuração.
Se você configurar a propriedade Modo de Depuração como true, deverá especificar argumentos de linha de comandos da depuração para a propriedade Argumentos de Depuração.
Tipo de Dados | Booleano |
Padrão | falso |
Especifica argumentos de depuração da linha de comandos a serem transmitidos para o código de JVM que inicia o processo do servidor de aplicativos. É possível especificar os argumentos quando a propriedade Modo de Depuração estiver configurada como true.
Se você ativar a depuração em vários servidores de aplicativos no mesmo nó, verifique se o mesmo valor não está especificado para o argumento de endereço. O argumento de endereço define a porta utilizada para depuração. Se dois servidores, para os quais a depuração esteja ativada, estiverem configurados para utilizar a mesma porta de depuração, os servidores podem não conseguir ser corretamente iniciados. Por exemplo, ambos os servidores ainda podem ser configurados com o argumento de depuração address=7777, que é o valor padrão para o argumento de endereço de depuração.
Se você ativar a depuração em vários servidores de aplicativos, verifique se o mesmo valor não está especificado para o argumento de endereço. O argumento de endereço define a porta utilizada para depuração. Se dois servidores, para os quais a depuração esteja ativada, estiverem configurados para utilizar a mesma porta de depuração, os servidores podem não conseguir ser corretamente iniciados. Por exemplo, ambos os servidores ainda podem ser configurados com o argumento de depuração address=7777, que é o valor padrão para o argumento de endereço de depuração.
Tipo de Dados | Cadeia |
Unidades | Argumentos da linha de comandos Java |
Especifica argumentos de linha de comandos para transmitir ao código da Java Virtual Machine que inicia o processo do servidor de aplicativos.
Especifique hotRestartSync, se deseja ativar o recurso hot restart sync do serviço de sincronização. Esse recurso indica para o serviço de sincronização que a instalação está executando em um ambiente no qual atualizações de configuração não são feitas quando o gerenciador de implementação não está ativo. Entretanto, o serviço não tem que desempenhar uma comparação de repositório completa quando o gerenciador de implementação ou os servidores do agente do nó forem reiniciados. Ativar esse recurso melhora a eficiência da primeira operação de sincronização após a reinicialização de um agente de nó ou gerenciador de implementação, especialmente para instalações que incluem células mistas de release, utilize vários nós e execute vários aplicativos.
Este argumento aplica-se apenas ao z/OS. Especifique o argumento -Dcom.ibm.CORBA.RequestTimeout= timeout_interval para configurar o período de tempo limite para responder aos pedidos enviados do cliente. Esse argumento utiliza a opção -D. timeout_interval é o período do tempo limite em segundos. Se a sua rede apresentar latência extrema, especifique um valor alto para evitar tempos limites. Se você especificar um valor muito pequeno, um servidor de aplicativos que participa do gerenciamento da carga de trabalho pode atingir o tempo limite antes de receber uma resposta.
Especifique este argumento apenas se seu aplicativo estiver passando por problemas com os tempos limites. Não há valores recomendados para esse argumento.
Este argumento aplica-se apenas ao z/OS. Especifique o argumento -Dcom.ibm.websphere.wlm.unusable.interval= timeout_interval para alterar o valor da propriedade com.ibm.websphere.wlm.unusable.interval quando o estado de gerenciamento de carga de trabalho do cliente estiver sendo atualizado muito antes ou muito depois. Esta propriedade especifica, em segundos, a quantidade de tempo que o tempo de execução do cliente de gerenciamento de carga de trabalho aguarda depois que marca um servidor como não disponível antes de tentar contato com o servidor novamente. Esse argumento utiliza a opção -D. . O valor padrão é 300 segundos. Se a propriedade for definida para um valor alto, o servidor será marcado como não disponível por um longo período de tempo. Isso impede que o protocolo de atualização do gerenciamento da carga de trabalho atualize o estado do gerenciamento da carga de trabalho do cliente até depois do período em que foi concluído.
Este argumento aplica-se apenas ao z/OS. Especifique o argumento -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl= para indicar que o armazenamento para buffers de byte diretos individuais deve ser liberado assim que o buffer não for mais necessário. O único valor suportado para este argumento é com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl.
-Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl
Na plataforma z/OS, você também precisa especificar esse argumento se
especificar a propriedade customizada zaioFreeInitialBuffers
para um canal TCP para que o canal libere os buffers de leitura inicial utilizados
em novas conexões assim que esses buffers não forem mais necessários para a conexão.
Especifica se a verificação de compatibilidade do SIP está ativada no servidor proxy do SIP. A verificação de compatibilidade do SIP assegura que as mensagens do SIP estejam em conformidade com o padrão do Session Initiation Protocol. Quando essa propriedade é configurada para true, a verificação de compatibilidade do SIP é ativada.
Java HotSpot Technology no Java SE 6 utiliza JVM adaptável contendo algoritmos que, com o passar do tempo, otimizam a forma como o código de byte é executado. A JVM é executada em dois modos, -server e -client. Na maioria dos casos, utilize o modo -server, que produz desempenho mais eficiente de tempo de execução sobre períodos de tempo estendidos.
Se você utilizar o modo -client padrão, o tempo de inicialização do servidor será mais rápido e será criada uma área de cobertura de memória menor. Entretanto, esse modo reduz o desempenho estendido. Utilize o modo -server, que melhora o desempenho, a menos que o tempo de inicialização do servidor seja de maior importância do que o desempenho. É possível monitorar o tamanho do processo e o tempo de inicialização do servidor para verificar a diferença de desempenho entre a utilização dos modos -client e -server.
Especifique -Xverify:none, se desejar ignorar o estágio de verificação de classe durante o carregamento de classe. O uso de -Xverify:none desativa a verificação de classe Java, o que pode fornecer uma melhora de 10-15 por cento no tempo de inicialização. Entretanto, dados de classe corrompidos ou inválidos não são detectados quando esse argumento é especificado. Se os dados de classe corrompidos forem carregados, a JVM pode se comportar de uma maneira inesperada ou a JVM pode falhar.
Especifique -Xnoclassgc se você desejar desativar a coleta de lixo de classes. Este argumento resulta em mais reutilização de classe e desempenho levemente aprimorado. No entanto, os recursos de propriedade dessas classes permanecem em uso mesmo quando as classes não estão sendo chamadas.
É possível utilizar a definição de configuração verbose:gc, se desejar monitorar a coleta de lixo. É possível utilizar a saída resultante para determinar o impacto de desempenho da reclamação desses recursos.
Se você especificar o argumento -Xnoclassgc, sempre que reimplementar um aplicativo, deve sempre reiniciar o servidor de aplicativos para limpar as classes e dados estáticos da versão anterior do aplicativo.
Especifique -Xgcthreads se você deseja utilizar vários encadeamentos de coleta de lixo ao mesmo tempo. Esta técnica de coleta de lixo é conhecida como coleta de lixo paralela. Esse argumento só é válido para o IBM Developer Kit.
Ao digitar este valor no campo Argumentos JVM Genéricos, digite também o número de processadores que estão sendo executados em sua máquina. Por exemplo, se você tiver 3 processadores sendo executados em sua máquina, digite -Xgcthreads 3. Em um nó com n processadores, o número padrão de encadeamentos é n.
Especifique -Xnocompactgc se você desejar desativar a compactação de heap. A compactação de heap é a operação de coleta de lixo mais cara. Se estiver utilizando o IBM Developer Kit, você deverá evitar a compactação do heap. Se a compactação do heap for desativada, todo o código extra associado será eliminado.
Especifique -Xgcpolicy para configurar a política de coleta de lixo. Esse argumento só é válido para o IBM Developer Kit.
Configure este argumento para optthruput, se desejar otimizar o rendimento e não criar um problema, se ocorrer longas pausas de coleta de lixo. É o parâmetro padrão, configuração recomendada.
Configure esse argumento para gencon, se você estiver usando um coletor de lixo de geração. O esquema de geração tenta alcançar um alto rendimento junto com tempos de pausa reduzidos da coleta de lixo. 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 é a mais adequada para todos os aplicativos e normalmente é mais difícil de ajustar.
Configure esse argumento como optavgpause, se desejar que a marcação simultânea seja utilizada para rastrear encadeamentos de aplicativos iniciando a partir da pilha, antes do heap ficar cheio. Quando esse parâmetro é especificado, as pausas do coletor de lixo tornam-se uniformes e as pausas longas não são aparentes. Entretanto, a utilização dessa política reduz o rendimento porque os encadeamentos podem precisar executar trabalho extra.
Configure esse argumento para subpool, se desejar aumentar o desempenho em sistemas multiprocessadores que normalmente usam mais de oito processadores. Essa política está disponível apenas nos processadores IBM System i, System p e System z. A política de subconjunto é semelhante à política optthruput, exceto pelo fato de que o heap é dividido em subconjuntos que fornecem escalabilidade melhorada para alocação de objeto.
O Java Platform, Standard Edition 6 (Java SE 6) possui coleta de lixo de geração, que permite que conjuntos de memórias separados contenham objetos com idades diferentes. O ciclo de coleta de lixo coleta os objetos de forma independente, de acordo com a idade. Com parâmetros adicionais, é possível definir o tamanho dos conjuntos de memória individualmente. Para alcançar melhor desempenho, configure o tamanho do conjunto que contém os objetos que possuem curtos ciclos de vida, de modo que os objetos no conjunto não sejam mantidos por mais de um ciclo de coleta de lixo. Utilize os parâmetros NewSize e MaxNewSize para especificar o tamanho do novo conjunto de geração.
-XX:NewSize=lower_bound -XX:MaxNewSize=upper_bound -XX:SurvivorRatio=new_ratio_size
Alternativamente, você poderia configurar de 50% a 60% do tamanho de heap total para um novo conjunto de geração.
Especifique -Xminf se você desejar alterar a porcentagem mínima de tamanho de heap livre. O heap aumenta se o espaço livre estiver abaixo do valor especificado. No modo ativado de reconfiguração, este argumento especifica a porcentagem mínima de espaço livre para os heaps de middleware e temporários. O valor especificado para este argumento é um número de vírgula flutuante, 0 a 1. O padrão é .3 (30 por cento).
Especifique o argumento -Xshareclasses:none para desativar a opção de compartilhamento de classes para um processo. A opção de compartilhamento de classes, que está disponível no Java SE 6, permite compartilhar 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.
Se você utilizar 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.
Tipo de Dados | Cadeia |
Unidades | Argumentos da linha de comandos Java |
Especifica o nome completo do caminho para um arquivo JAR executável utilizado pelo código de JVM.
Tipo de Dados | Cadeia |
Unidades | Nome do Caminho |
Especifica se deve desativar a opção do compilador em determinado momento (JIT) do código JVM.
Se o compilador JIT for desativado, o rendimento do processamento será reduzido ostensivamente. Assim, por questões de desempenho, mantenha o JIT ativado.
Tipo de Dados | Booleano |
Padrão | false (JIT ativado) |
Recomendado | JIT ativado |
Especifica definições da JVM para um determinado sistema operacional.
Quando o processo é iniciado, ele utiliza as configurações JVM que são especificadas para o servidor como as configurações JVM para o sistema operacional.
Quando o processo é iniciado, ele utiliza as configurações JVM que são especificadas para o nó como as configurações JVM para o sistema operacional.
Links marcados (on-line) requerem acesso à Internet.