Configurações da Java Virtual Machine

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 essa página do console administrativo, conecte-se ao console administrativo e navegue no painel da Java virtual machine.

[z/OS]Para a plataforma z/OS, siga um dos seguintes caminhos.
Informações Valor
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 Java e de 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 Java e de Processo > Definição de Processo > Java Virtual Machine
[AIX Solaris HP-UX Linux Windows][IBM i]Para o IBM i e as plataformas distribuídas, siga um dos caminhos a seguir.
Informações Valor
Servidor de Aplicativos Servidores > Tipos de servidor > Servidores de aplicativos do WebSphere > server_name . Em seguida, na seção Infraestrutura do Servidor, clique em Gerenciamento Java e de Processo > 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 Java e de Processo > 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 Java e de Processo > Definição de Processo > Java Virtual Machine

Classpath

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.

Os únicos caminhos de classe que devem ser incluídos neste campo são aqueles que especificam o local dos seguintes itens:
  • Uma ferramenta de inspeção ou monitoramento para seu sistema.
  • Arquivos JAR para um produto que executa no topo desse produto.
  • Correções de diagnóstico da JVM.
Podem ocorrer erros de processamento se você incluir caminhos de classe neste campo que especifiquem o local dos seguintes itens:
  • Arquivos JAR para provedores de recursos, como DB2. Os caminhos para estes arquivos JAR devem ser incluídos nos caminhos de classe de provedor relevantes.
  • Um arquivo JAR de usuário que é utilizado por um ou mais dos aplicativos que você está executando no produto. O caminho para este tipo de arquivo JAR deve ser especificado dentro de cada aplicativo que requer esse arquivo JAR ou em bibliotecas compartilhadas associadas ao servidor.
  • Um arquivo JAR de extensão. Se você precisar incluir um arquivo de extensão JAR no sistema, deverá utilizar a propriedade customizada da JVM ws.ext.dirs para especificar o caminho absoluto para este arquivo JAR. Também é possível colocar o arquivo JAR no diretório WAS_HOME/lib/ext/, mas utilizar a propriedade customizada da JVM ws.ext.dirs é a abordagem recomendada para especificar o caminho para um arquivo de extensão JAR.
Informações Valor
Tipo de Dados String

Caminho de Classe de Inicialização

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 o nó reside, para separar esses caminhos de classe.

Os únicos caminhos de classe que devem ser incluídos neste campo são aqueles que especificam o local dos seguintes itens:
  • Uma ferramenta de inspeção ou monitoramento para seu sistema.
  • Arquivos JAR para um produto que executa no topo desse produto.
  • Correções de diagnóstico da JVM.
Podem ocorrer erros de processamento se você incluir caminhos de classe neste campo que especifiquem o local dos seguintes itens:
  • Arquivos JAR para provedores de recursos. como o DB2. Os caminhos para estes arquivos JAR devem ser incluídos nos caminhos de classe de provedor relevantes.
  • Um arquivo JAR de usuário que é utilizado por um ou mais dos aplicativos que você está executando no produto. O caminho para este tipo de arquivo JAR deve ser especificado dentro de cada aplicativo que requer esse arquivo JAR ou em bibliotecas compartilhadas associadas ao servidor.
  • Um arquivo JAR de extensão. Se você precisar incluir um arquivo de extensão JAR no sistema, deverá utilizar a propriedade customizada da JVM ws.ext.dirs para especificar o caminho absoluto para este arquivo JAR. Também é possível colocar o arquivo JAR no diretório WAS_HOME/lib/ext/, mas utilizar a propriedade customizada da JVM ws.ext.dirs é a abordagem recomendada para especificar o caminho para um arquivo de extensão JAR.

Carregamento da Classe do Modo Detalhado

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.

[AIX Solaris HP-UX Linux Windows]Se o carregamento de classe detalhada for ativado, a saída de depuração será enviada para um dos logs de processo nativos.

Informações Valor
Tipo de dados Booleano
Padrão false

Coleção de lixo do modo detalhado

Especifica se deve utilizar a saída de depuração detalhada para coleção de lixo. O padrão é não ativar a coleção de lixo detalhada.

[AIX Solaris HP-UX Linux Windows]Se a coleção de lixo detalhada for ativada, a saída de depuração será enviada para um dos logs de processo nativos.

Informações Valor
Tipo de Dados Booleano
Default falso

Quando esse campo está ativado, um relatório é gravado no fluxo de saída cada vez que o coletor de lixo é executado. Este relatório deve fornecer uma indicação de como o processo de coleta de lixo do Java está funcionando.

Você pode verificar o relatório verboseGC para determinar:
  • Quanto tempo a JVM está gastando para executar a coleção de lixo.
    Idealmente, você deseja que a JVM gaste menos de 5 por cento de seu tempo de processamento executando a coleta de lixo. Para determinar a porcentagem de tempo que a JVM gasta na coleta de lixo, divida o tempo que demorou para concluir a coleta pelo período de tempo desde o último AF e multiplique o resultado por 100. Por exemplo:
    83.29/3724.32 * 100 = 2.236 por cento

    Se você estiver gastando mais de 5 por cento de seu tempo em coleta de lixo e se a coleta de lixo estiver ocorrendo frequentemente, poderá precisar aumentar o tamanho de heap do Java.

  • Se o heap alocado estiver aumentando a cada ocorrência de coleta de lixo.

    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 coleção de lixo para coleção de lixo. Esta situação pode indicar que seu aplicativo possui uma fuga de memória.

Para Usuários de Transição Para Usuários de Transição: A versão 7.0 e as versões anteriores usam o algoritmo de coleção de lixo optthruput. Na Versão 8.0 e posterior, o padrão é configurado como o coletor de lixo de geração. Esse algoritmo de coleção de lixo pode aumentar o desempenho. A opção da JVM a seguir é incluída no comando de inicialização do WebSphere Application Server: -Xgcpolicy:gencon. Se preferir usar o algoritmo de coleta de lixo optthruput, é possível remover -Xgcpolicy:gencon e o algoritmo de coleta de lixo optthruput será usado.trns

[z/OS]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, é possível 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.

Verbose JNI

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.

Informações Valor
Tipo de Dados Booleano
Default falso

Tamanho de Heap Inicial

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.

[z/OS]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 às configurações de 32 e de 64 bits.

[AIX Solaris HP-UX Linux Windows][IBM i]Para o IBM® i e plataformas distribuídas, o tamanho de heap inicial padrão é de 50 MB.

Boas Práticas Boas Práticas: Esses valores padrão são suficientes para a maioria dos aplicativos.bprac
Evitar Problemas Evitar Problemas: Para IBM i, o tamanho de heap inicial deve sempre ser menor que o tamanho de heap máximo. Nunca configure as propriedades tamanho de heap inicial e tamanho de heap máximo para o mesmo valor.gotcha

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 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.

Tamanho Máximo de Heap

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. Esse valor padrão se aplica às configurações de 32 e de 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.

[z/OS]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.

Boas Práticas Boas Práticas: Esses valores padrão são apropriados para a maioria dos aplicativos. Ative a propriedade Coleta de Lixo Detalhada se você achar que a coleta de lixo está ocorrendo com muita freqüência. Se a coleta de lixo estiver ocorrendo com muita freqüência, aumente o tamanho máximo do heap JVM.bprac
[AIX Solaris HP-UX Linux Windows][IBM i]

Executar HProf

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.

Informações Valor
Tipo de Dado Booleana
Padrão falso
[AIX Solaris HP-UX Linux Windows][IBM i]

Argumentos HProf

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.

Modo de Depuração

Especifica se a JVM deve ser executada no modo de depuração. O padrão é não ativar o suporte ao 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.

Informações Valor
Tipo de Dados Booleano
Default falso

Argumentos de Depuração

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.

Informações Valor
Tipo de Dados String
Unidades Argumentos de Linha de Comandos Java

Argumentos JVM Genéricos

Especifica argumentos de linha de comandos para transmitir ao código da Java Virtual Machine que inicia o processo do servidor de aplicativos.

É possível digitar os seguintes argumentos opcionais da linha de comando no campo Argumentos JVM Genéricos. Se você digitar mais de um argumento, digite um espaço entre cada argumento.
Evitar Problemas Evitar Problemas: Se o argumento declarar que serve apenas para o IBM Developer Kit, você não poderá utilizar esse argumento com a JVM de outro provedor, como Microsoft ou Hewlett-Packardgotcha
  • [z/OS][AIX Solaris HP-UX Linux Windows]-DhotRestartSync:

    Especifique -DhotRestartSync se desejar 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.

  • -Dcom.ibm.crypto.provider.doAESInHardware:

    Configure essa opção para true se desejar ativar a função Padrão de Criptografia Avançado (AES) que é fornecida com o IBM SDK e Runtime Environment para AIX, Java Technology Edition, Versão 7. AES é uma cifra de bloco simétrico que criptografa e decriptografa dados por várias rodadas. A ativação dessa função resultou em melhorias de desempenho no processamento de SSL do WebSphere Application Server.

  • [AIX Solaris HP-UX Linux Windows][z/OS]-Xquickstart
    Especifique -Xquickstart se deseja que a compilação inicial ocorra em um nível de otimização inferior ao do modo padrão. Posteriormente, dependendo dos resultados da amostragem, é possível recompilar para o nível da compilação inicial no modo padrão.
    Boas Práticas Boas Práticas: Utilize -Xquickstart para aplicativos nos quais a velocidade moderada inicial é mais importante que um rendimento do processamento a longo prazo. Em alguns cenários de depuração, canais de teste e ferramentas de curta execução, é possível aprimorar o tempo de inicialização entre 15 a 20 por cento.bprac
    Evitar Problemas Evitar Problemas: IBM i não suporta este argumento.gotcha
  • [AIX Solaris HP-UX Linux Windows][z/OS]-Xverify:none

    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. No entanto, os dados de classe corrompidos ou inválidos não são detectados quando este argumento for especificado. Se os dados de classe corrompidos forem carregados, a JVM pode se comportar de uma maneira inesperada ou a JVM pode falhar.

    Evitar Problemas Evitar Problemas:
    • Não utilize este argumento, se estiver fazendo modificações de código de byte, porque a JVM pode falhar, se ocorrer qualquer erro de instrumentação.
    • Se você tiver uma falha de JVM ou se a JVM se comportar de uma maneira inesperada enquanto este argumento estiver em vigor, remova este argumento como sua primeira etapa na depuração de seu problema de JVM.
    • [IBM i]O IBM i não suporta esse argumento.
    gotcha
  • [AIX Solaris HP-UX Linux Windows][z/OS]-Xnoclassgc

    Especifique -Xnoclassgc, se desejar desativar a coleta de lixo de classe. 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.

    Evitar Problemas Evitar Problemas: O impacto da coleta de lixo de classe no desempenho é tipicamente mínimo, e desligar a coleta de lixo de classe em um sistema baseado em Java Platform, Enterprise Edition (Java EE), com sua utilização mais intensa de carregadores de classes de aplicativo, poderá efetivamente criar uma fuga de memória de dados de classe, e fazer com que a JVM gere um Exceção de Falta de Memória.gotcha

    É 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, sempre será necessário reiniciar o servidor de aplicativos para limpar as classes e dados estáticos da versão anterior do aplicativo.

    Evitar Problemas Evitar Problemas: O IBM i não suporta esse argumento. Você deve usar o argumento -noclassgc para desativar a coleta de lixo da classe nesta plataforma.gotcha
  • [AIX Solaris HP-UX Linux Windows][z/OS]-Xgcthreads

    Especifique -Xgcthreads, se desejar utilizar vários encadeamentos de coleta de lixo de uma vez. Esta técnica de coleção de lixo é conhecida como coleção 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.

    Especifique -Xgcthreads da seguinte forma:

    -Xgcthreads<número de processadores>

    Evitar Problemas Evitar Problemas: Não inclua um espaço entre --Xgcthreads e valor n para o número de processadores.

    -Xgcthreads5 é um exemplo de como especificar -Xgcthreads com 5 processadores.

    gotcha
    Boas Práticas Boas Práticas: Você deve utilizar a coleta de lixo paralela, se sua máquina tiver mais de um processador.bprac
    Evitar Problemas Evitar Problemas: IBM i não suporta este argumento.gotcha
  • [AIX Solaris HP-UX Linux Windows][z/OS]-Xnocompactgc

    Especifique -Xnocompactgc, se 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.

    Evitar Problemas Evitar Problemas: O IBM i não suporta esse argumento.gotcha
  • [AIX Solaris HP-UX Linux Windows][z/OS]-Xgcpolicy

    Especifique -Xgcpolicy para configurar a política de coleta de lixo. Esse argumento só é válido para o IBM Developer Kit.

    Configure este argumento como optthruput se desejar otimizar o rendimento, e ele não criará um problema se ocorrer uma pausa na coleta de lixo longa.

    Configure esse argumento como gencon, se estiver usando um coletor de lixo de geração. O esquema de 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. Objetos de vida longa são promovidos para o espaço antigo enquanto objetos de vida curta são lixo coletado rapidamente no novo espaço. A política gencon fornece benefícios significativos para muitos aplicativos. Entretanto, ela não é adequada para todos os aplicativos e, normalmente, é mais difícil de ajustar.

    Configure este argumento para optavgpause, se desejar que a marcação simultânea seja utilizada para rastrear os encadeamentos de aplicativo que iniciam da pilha antes que o heap fique cheio. Quando este parâmetro for especificado, as pausas do coletor de lixo ficarão uniformes e as longas pausas não serão aparentes. Entretanto, a utilização dessa política reduz o rendimento porque os encadeamentos podem precisar executar trabalho extra.

    Configure esse argumento como subpool, se você deseja aumentar o desempenho em sistemas multiprocessadores, que geralmente usam mais de oito processadores. Essa política está disponível nos processadores IBM System i, System p e System z. A política subpool é semelhante à política optthruput, exceto que o heap é dividido em subconjuntos que fornecem melhor escalabilidade para a alocação de objetos.

    Evitar Problemas Evitar Problemas: O IBM i não suporta esse argumento.gotcha
  • [AIX Solaris HP-UX Linux Windows][z/OS]-XX

    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 no novo conjunto de geração.

    Os objetos que sobrevivem ao primeiro ciclo de coleta de lixo são transferidos para outro conjunto. Utilize o parâmetro SurvivorRatio para especificar o tamanho do conjunto sobrevivente. SurvivorRatio. Você pode utilizar as estatísticas de objeto coletadas pelo Tivoli Performance Viewer ou incluir o argumento verbose:gc na definição de configuração para monitorar estatísticas de coleta de lixo. Se a coleta de lixo se tornar um gargalo, especifique os seguintes argumentos para customizar as configurações do conjunto de geração para se adequar melhor ao seu ambiente.
    -XX:NewSize=lower_bound 
    -XX:MaxNewSize=upper_bound
     -XX:SurvivorRatio=new_ratio_size 
    Os valores padrão são:
    • NewSize=2m
    • MaxNewSize=32m
    • SurvivorRatio=32
    Boas Práticas Boas Práticas: No entanto, se tiver uma JVM com tamanho de heap acima de 1 GB, você deve utilizar os seguintes valores:
    • -XX:NewSize=640m
    • -XX:MaxNewSize=640m
    • -XX:SurvivorRatio=16
    bprac

    Alternativamente, você poderia configurar de 50% a 60% do tamanho de heap total para um novo conjunto de geração.

    Evitar Problemas Evitar Problemas: O IBM i não suporta esse argumento.gotcha
  • [AIX Solaris HP-UX Linux Windows][z/OS]-Xminf

    Especifique -Xminf, se deseja 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).

    Evitar Problemas Evitar Problemas: O IBM i não suporta esse argumento.gotcha
  • [AIX Solaris HP-UX Linux Windows][z/OS]-server | -client

    O Java HotSpot Technology em Java SE 6 utiliza uma JVM adaptativa contendo algoritmos que, ao longo do tempo, otimizam como o bytecode é 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. No entanto, este modo diminui 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.

    Evitar Problemas Evitar Problemas: O IBM i não suporta esse argumento.gotcha
  • -Dcom.ibm.CORBA.RequestTimeout=timeout_interval

    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 usa a opção -D. timeout_interval é o período de 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 este argumento.

  • -Dcom.ibm.server.allow.sigkill=true

    O argumento -Dcom.ibm.server.allow.sigkill=true permite que o processo do agente do nó utilize o método terminate de um processo quando o método stop não concluir dentro do intervalo de tempo especificado para o intervalo de Ping. Essa configuração é útil quando o agente do nó estiver monitorando um servidor de aplicativos e perder contato com ele.

    Quando a política de monitoramento para o servidor de aplicativos permitir que o agente do nó reinicie o servidor de aplicativos porque a reinicialização automática está ativada para o servidor de aplicativos, o agente do nó executará o método stop no processo do servidor de aplicativos. Durante o processamento da parada, o agente do nó irá monitorar o servidor de aplicativos e se o servidor de aplicativos não parar dentro do intervalo de tempo especificado para o intervalo de Ping, e esse argumento estiver configurado como true, que é o valor padrão, o agente do nó executará o método terminate no processo do servidor de aplicativos para parar o processo do servidor de aplicativos.

    Se você configurar esse argumento como false, o agente do nó continuará a monitorar o processamento de parada, mas não tentará reinicializar o servidor de aplicativos.

    Para usar o console administrativo para desativar esse argumento, clique em Administração do Sistema > Agentes de Nó > nodeagent_name > Gerenciamento de Processo & Java > Definição de Processo > Java Virtual Machine > Argumentos Genéricos da JVM.

  • -Dcom.ibm.websphere.alarmthreadmonitor.hung_alarm_mute=

    Esse argumento especifica o número máximo de vezes que um alarme relata seu rastreio de pilha completo em mensagens de encadeamento interrompido nos log do sistema.

    Quando um encadeamento de alarme de sistema fica ativo por mais tempo do que o limite do monitor de encadeamento de alarme, o servidor de aplicativos registra uma mensagem de encadeamento interrompido com um nome igual ao do encadeamento de alarme, o período em que o encadeamento de alarme permaneceu ativo e o rastreio completo de pilha de exceções. O rastreio completo de pilha é útil para depuração da causa do atraso, mas se as mensagens de encadeamento interrompido forem acionadas com frequência, as mensagens longas repetidas poderão dificultar a localização de outras informações no sistema. Configure esse argumento para um número inteiro maior que 0 para especificar o número máximo de vezes que um alarme único qualquer relata seu rastreio completo de pilha. Após esse limite ser atingido, cada mensagem de encadeamento interrompido subsequente incluirá somente a entrada do manipulador de alarme interrompido.

    O valor padrão 0 indica que todas as mensagens de encadeamento interrompido para um alarme incluem o rastreio completo de pilha.

    Nota: Essa propriedade especifica um limite para cada classe manipuladora de alarme, não para o número total de mensagens ou para cada instância de manipulador de alarme.
  • -Dcom.ibm.websphere.native.logging.timestamp=true

    Especifique esse argumento para incluir um registro de data e hora e um identificador de encadeamento antes de todas as mensagens de depuração do servidor que são a saída dos arquivos de log native_stdout e native_stderr. É possível usar o registro de data e hora e o identificador de encadeamento para correlacionar os comportamentos dos componentes de autoinicialização do servidor de aplicativos com os comportamentos de outros mecanismos do servidor, que são indicados nos arquivos de log SystemOut e SystemErr. Esse comportamento é desativado, por padrão.

    Quando o servidor é configurado com o argumento genérico da JVM -Dws.ext.debug=true, ele emite mensagens de depuração durante sua sequência de autoinicialização para native_stdout.log e native_stderr.log. Quando -Dcom.ibm.websphere.native.logging.timestamp também está configurado como true, o servidor envia mensagens de depuração com um registro de data e hora e um identificador de encadeamento, conforme mostra o exemplo a seguir:

    [6/18/12 16:24:31:453 CDT] 00000000 
    ws.ext.mains.args[0]=-nosplash
    [6/18/12 16:24:31:453 CDT] 00000000 
    ws.ext.mains.args[1]=-application
    [6/18/12 16:24:31:453 CDT] 00000000 
    ws.ext.mains.args[2]=com.ibm.ws.bootstrap.WSLauncher
    [6/18/12 16:24:31:453 CDT] 00000000 
    ws.ext.mains.args[3]=com.ibm.ws.runtime.WsServer
    Nota: Você deve especificar -Dws.ext.debug=true apenas sob a direção da equipe de suporte IBM.
  • -Dcom.ibm.ws.wim.registry.DbSharedAcrossMultipleServers=true

    Especifique -Dcom.ibm.ws.wim.registry.DbSharedAcrossMultipleServers=true quando os repositórios DB/LA do Virtual member manager forem compartilhados entre diferentes instalações. Essa propriedade não destina-se ao uso em ambientes em cluster. A configuração dessa propriedade permite que o VMM sincronize chamadas de instalações do WebSphere Application Server que compartilham repositórios.

  • [z/OS]-Dcom.ibm.websphere.wlm.unusable.interval=interval

    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.

  • [z/OS]-Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=

    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 esse argumento é com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl.

    Os buffers de byte direto, que a JVM cria para manipular dados do pedido, são alocados no heap do Language Environment (LE) e não no heap da JVM. Geralmente, mesmo se os buffers de byte direto não forem mais necessários, a JVM não liberará o armazenamento de LE nativo até que ocorra a próxima coleção de lixo. Se o servidor estiver manipulando grandes pedidos, o armazenamento do LE pode se esgotar antes que a JVM execute um ciclo de coleção de lixo, fazendo com que o servidor encerre de forma anormal (abend). Configurar a JVM com o seguinte argumento impede que ocorra esses encerramentos anormais.
    -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl

    [z/OS]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.

  • [z/OS]-DisSipComplianceEnabled=true|false

    Especifica se a verificação de conformidade SIP está ativada no servidor proxy SIP. A verificação de conformidade SIP assegura que as mensagens SIP estejam em conformidade com o padrão Session Initiation Protocol. Quando essa propriedade está configurada como true, a verificação de conformidade SIP está ativada.

    Evitar Problemas Evitar Problemas: Se estiver executando um servidor proxy em um ambiente z/OS WebSphere Application Server, Network Deployment, e seu servidor proxy não fizer parte de um cluster, você pode utilizar a propriedade customizada do servidor proxy SIP isSipComplianceEnabled para ativar ou desativar a verificação de conformidade com SIP para esse servidor proxy SIP. No entanto, se você estiver executando um servidor de aplicativos independente ou se o seu servidor proxy não for parte de um cluster, é necessário usar esse argumento da JVM genérico para ativar ou desativar a verificação de conformidade do SIP.gotcha
  • [AIX Solaris HP-UX Linux Windows][z/OS]-Xshareclasses:none

    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 ou pare o processo e, em seguida, reinicie-o.

    Nota: Ao usar clearClassCache para limpar o cache inteiro, deve-se parar todas as JVMs conectadas.
    Evitar Problemas Evitar Problemas:
    • [Solaris][IBM i][HP-UX]O IBM JVM para J2SE 5 não é suportado no Solaris, HP e IBM i.
    • As classes de aplicativos Java EE em execução em um processo de servidor de aplicativos não são incluídas no cache de classe compartilhado.
    gotcha
  • -XXallowvmshutdown:false

    Utilize o argumento -XXallowvmshutdown:false para reverter para um comportamento anterior para a JVM que não está correta. Java 5.0 SR10 e Java 6 SR5 corrigem problemas nos quais o Java Virtual Machine (JVM) não é encerrado corretamente. Se você tiver um aplicativo que depende do comportamento antigo, é possível reverter para o comportamento anterior incluindo esse argumento na seção Argumentos Genéricos da JVM.

Informações Valor
Tipo de Dados String
Unidades Argumentos de Linha de Comandos Java

Nome do Arquivo JAR Executável

Especifica o nome completo do caminho para um arquivo JAR executável utilizado pelo código de JVM.

Informações Valor
Tipo de Dados String
Unidades Nome do Caminho

Desativar JIT

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.

Informações Valor
Tipo de Dados Booleano
Default false (JIT ativado)
Recomendado JIT ativado

Nome do sistema operacional

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 nó como as configurações JVM para o sistema operacional.


Ícone que indica o tipo de tópico Tópico de Referência



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=urun_rconfproc_jvm
Nome do arquivo: urun_rconfproc_jvm.html