Definições da Java Virtual Machine

Utilize essa página para visualizar e alterar as definições de configuração da JVM (Java Virtual Machine) de um processo para um servidor de aplicativos.

Para visualizar essa página do console administrativo, conecte-se ao console administrativo e navegue para o painel Java Virtual Machine.

[AIX Solaris HP-UX Linux Windows] [iSeries] Para plataformas i5/OS e distribuídas, clique em Servidores > Tipos de Servidores > Servidores de Aplicativos WebSphere > server_name. Em seguida, na seção Infra-estrutura do Servidor, clique em Gerenciamento de Java e Processos > Definição de Processo > Java Virtual Machine

[z/OS] Para a plataforma z/OS, siga um dos caminhos a seguir.
Servidor de Aplicativos Clique em Servidores > Tipos de Servidores > Servidores de Aplicativos WebSphere > server_name. Em seguida, na seção Infra-estrutura 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 do Sistema > Gerenciador de Implementação. Em seguida, na seção Infra-estrutura 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 Infra-estrutura do Servidor, clique em Gerenciamento de Java e Processos > Definição de Processo > Java Virtual Machine
[AIX Solaris HP-UX Linux Windows] [iSeries] Para plataformas i5/OS e distribuídas, siga um dos caminhos a seguir.
Servidor de Aplicativos Servidores > Tipos de Servidores > Servidores de Aplicativos WebSphere > server_name. Em seguida, na seção Infra-estrutura 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 Infra-estrutura 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 Infra-estrutura do Servidor, clique em Gerenciamento de Java e Processos > Definição de Processo > Java Virtual Machine

Guia Configuração

Caminho de Classe

Especifica o caminho da classe padrão no qual o código da Java virtual machine procurar por classes.

Digite cada entrada de caminho de classe em uma linha da tabela. Não é necessário incluir os dois pontos ou ponto e vírgula no final de cada entrada.

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.

Você pode separar vários caminhos por dois-pontos (:) ou ponto-e-vírgula (;), dependendo do sistema operacional no qual a JVM reside.

Você pode separar vários caminhos por dois-pontos (:) ou ponto-e-vírgula (;), dependendo do sistema operacional no qual o nó reside.

Tipo de Dados Cadeia
Carregamento de Classe Detalhada

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 a um dos logs do processo nativo.

Tipo de Dados Booleano
Padrão falso
Coleta de Lixo Detalhada

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.

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

,

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.

Você pode verificar o relatório verboseGC para determinar:
  • Quanto tempo a JVM está gastando para desempenhar a coleta de lixo.
    De modo ideal, você deseja que a JVM gaste menos de 5 por cento de seu tempo de processamento para desempenhar a coleta de lixo. Para determinar a porcentagem de tempo que a JVM gasta na coleta de lixo, divida o tempo que ela levou para concluir a coleta pelo período de tempo desde o último AF e multiplique o resultado por 100. Exemplo:
    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 que esteja ocorrendo com freqüência, pode ser necessário aumentar o tamanho de heap 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 fica desalocada após cada ciclo de coleta de lixo e verifique se a porcentagem não está continuando a declinar. Se a porcentagem de espaço livre continuar seu declínio, significa que está havendo um aumento gradual no tamanho de heap de uma coleta de lixo para outra. Essa situação pode indicar uma fuga de memória no aplicativo.

[z/OS] Na plataforma z/OS, também é possível emitir o comando do 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 do heap da JVM também é disponibilizado para o 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 JNI (Java Native Interface) detalhada.

Tipo de Dados Booleano
Padrão falso
Tamanho de Heap Inicial

Especifica o tamanho de heap inicial disponível para o código de JVM, em megabytes.

O aumento do tamanho mínimo do heap pode melhorar a inicialização. O número de ocorrências de coleta de lixo é reduzido e obtém-se um ganho de 10 por cento no desempenho.

O aumento do tamanho de heap Java melhora o rendimento até que o heap não resida mais na memória física. Entretanto, 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 do Java.

[iSeries] Evitar Problemas: Para o i5/OS, o tamanho de heap mínimo deve sempre ser menor do que o tamanho máximo de heap. Nunca configure as propriedades tamanho mínimo de heap e tamanho máximo de heap para o mesmo valor. gotcha
Tipo de Dados Inteiro
Padrão

[z/OS] Para z/OS, o padrão para o controlador é 48 e o padrão para o servant é 128. Esses valores padrão se aplicam às configurações de 31 bits e 64 bits.

[AIX Solaris HP-UX Linux Windows] [iSeries] Para plataformas distribuídas, o padrão é 50.

Boas Práticas: Esses valores padrão são suficientes para a maioria dos aplicativos.bprac
Tamanho Máximo de Heap

Especifica o tamanho de heap máximo disponível para o código de JVM, em megabytes.

O aumento do tamanho do heap pode melhorar a inicialização. Aumentando o tamanho de heap, você pode reduzir o número de ocorrências de coleta de lixo com um ganho de 10 por cento no desempenho.

O aumento do tamanho do heap Java normalmente aprimora o rendimento do processamento até que o heap não resida mais na memória física. Quando o tamanho de heap excede a memória física, o heap começa a paginar dados, o que ocasiona a redução drástica no desempenho do Java. Portanto, é importante definir o tamanho máximo de heap com um valor que permita ao heap estar contido na memória física.

Para evitar a paginação, especifique um valor para essa propriedade que permita 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. O aumento do tamanho máximo de heap pode reduzir o desempenho em vez de melhorá-lo.

[iSeries] Para i5/OS, quando essa propriedade é configurada para 0, o coletor de lixo é executado apenas quando seu limite é alcançado. Quando um valor diferente de 0 é especificado, o coletor de lixo é executado sempre que o tamanho de heap alcança o tamanho máximo especificado. Entretanto, diferente de um coletor de lixo normal, se o tamanho máximo for alcançado, todos os encadeamentos do aplicativo deverão aguardar até que o processo de coleta de lixo seja concluído antes de poderem continuar a execução. Essa situação pode causar tempos de pausa indesejáveis. Portanto, utilize o tamanho máximo de heap como uma rede de segurança para manipular ocorrências de aumento inesperado de heap e para assegurar que o heap não aumente mais que a memória disponível. Em circunstâncias normais, o tamanho máximo de heap especificado nunca é alcançado.

Tipo de Dados Inteiro
Padrão

Para z/OS, o padrão é 256. Mantenha o valor baixo o bastante para evitar paginação.

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 da JVM.bprac
Executar HProf [AIX Solaris HP-UX Linux Windows] [iSeries]

Especifica se o suporte ao gerenciador de perfis HProf deve ser utilizado. Para utilizar um outro gerenciador de perfis, especifique as configurações customizadas do gerenciador de perfis utilizando a configuração Argumentos de HProf. O padrão é não ativar o suporte ao gerenciador de perfis HProf.

Se você configurar a propriedade Executar HProf como true, deverá especificar argumentos de linha de comandos do gerenciador de perfis para a propriedade Argumentos de HProf.

Tipo de Dados Booleano
Padrão falso
Argumentos HProf [AIX Solaris HP-UX Linux Windows] [iSeries]

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. Você pode especificar argumentos quando o suporte ao criador de perfil HProf está ativado.

Os argumentos de HProf serão necessários apenas se a propriedade Executar HProf for configurada como 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.

Tipo de Dados Booleano
Padrão 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. Os argumentos podem ser especificados quando a propriedade Modo de Depuração é 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 address. O argumento address define a porta que é utilizada para depuração. Se dois servidores, para os quais a depuração estiver ativada, forem configurados para utilizar a mesma porta de depuração, os servidores poderão não iniciar corretamente. Por exemplo, ambos os servidores podem estar configurados com o argumento de depuração address=7777, que é o valor padrão para o argumento address 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 address. O argumento address define a porta que é utilizada para depuração. Se dois servidores, para os quais a depuração estiver ativada, forem configurados para utilizar a mesma porta de depuração, os servidores poderão não iniciar corretamente. Por exemplo, ambos os servidores podem estar configurados com o argumento de depuração address=7777, que é o valor padrão para o argumento address de depuração.

Tipo de Dados Cadeia
Unidades Argumentos da linha de comandos Java
Argumentos JVM Genéricos

Especifica argumentos de linha de comandos a serem transmitidos para o código de Java Virtual Machine que inicia o processo do servidor de aplicativos.

Você pode digitar os argumentos opcionais de linha de comandos, a seguir, no campo Argumentos JVM Genéricos. Se você digitar mais de um argumento, digite um espaço entre cada argumento.
Evitar Problemas: Se o argumento for declarado como destinado apenas ao IBM Developer Kit, você não poderá utilizá-lo com a JVM de um outro provedor, como Microsoft ou Hewlett-Packardgotcha
  • [z/OS] [AIX Solaris HP-UX Linux Windows] hotRestartSync:

    Especifique hotRestartSync se você desejar ativar o recurso de sincronização de reinício automático do serviço de sincronização. Esse recurso indica ao serviço de sincronização que a instalação está sendo executada 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. A ativação desse recurso melhora a eficiência da primeira operação de sincronização depois que o gerenciador de implementação ou um agente do nó é reiniciado, especialmente para instalações que incluem células de liberação mista, utilizam vários nós e executam vários aplicativos.

  • [AIX Solaris HP-UX Linux Windows] [z/OS] -Xquickstart
    Especifique -Xquickstart se você desejar que a compilação inicial ocorra em um nível de otimização inferior ao 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: 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, conjuntos de teste e ferramentas de execução curta, você pode melhorar o tempo de inicialização entre 15 e 20 por cento.bprac
    [iSeries] Evitar Problemas: O i5/OS não suporta este argumento.gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -Xverify:none

    Especifique -Xverify:none se você desejar ignorar o estágio de verificação de classe durante o carregamento de classes. A utilização de -Xverify:none desativa a verificação de classe Java, que pode fornecer um aprimoramento de 10 a 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 dados de classe corrompidos forem carregados, a JVM pode comportar-se de uma maneira inesperada ou pode falhar.

    Evitar Problemas:
    • Não utilize esse argumento se você estiver fazendo modificações de bytecode, pois a JVM poderá falhar se ocorrer um erro de instrumentação.
    • Se você encontrar uma falha da JVM ou a JVM comportar-se de uma maneira inesperada enquanto esse argumento estiver em vigor, remova esse argumento como sua primeira etapa ao depuração o problema da JVM.
    • [iSeries] O i5/OS não suporta este argumento.
    gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -Xnoclassgc

    Especifique -Xnoclassgc se você desejar desativar a coleta de lixo de classes. Esse argumento resulta em mais reutilização de classes e desempenho um pouco melhor. Entretanto, os recursos pertencentes a essas classes permanecem em uso mesmo quando as classes não estão sendo chamadas. Você poderá utilizar a definição de configuração verbose:gc se desejar monitorar a coleta de lixo. A saída resultante pode ser utilizada para determinar o impacto no desempenho da recuperação desses recursos. Se o mesmo conjunto de classes tiver o lixo coletado repetidamente, convém desativar a coleta de lixo de classes. A coleta de lixo da classe fica ativada por padrão.

    [iSeries] Evitar Problemas: O i5/OS não suporta este argumento. É necessário utilizar -noclassgc para desativar a coleta de lixo de classes nessa plataforma.gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -Xgcthreads

    Especifique -Xgcthreads se você deseja utilizar vários encadeamentos de coleta de lixo ao mesmo tempo. Essa técnica de coleta de lixo é conhecida como coleta de lixo paralela. Esse argumento é válido somente para o IBM Developer Kit.

    Ao digitar esse valor no campo Argumentos JVM Genéricos, digite também o número de processadores em execução na máquina. Por exemplo, se você tiver 3 processadores em execução na máquina, digite -Xgcthreads 3. Em um nó com n processadores, o número padrão de encadeamentos é n.

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

    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 você estiver utilizando o IBM Developer Kit, deverá evitar a compactação de heap. Se a compactação do heap for desativada, todo o código extra associado será eliminado.

    [iSeries] Evitar Problemas: O i5/OS não suporta este argumento.gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -Xinitsh

    Especifique -Xinitsh se você desejar configurar o tamanho de heap inicial para objetos de classe. As definições de métodos e os campos estáticos são armazenados com objetos de classe. Você pode utilizar esse argumento apenas com o IBM Developer Kit.

    Embora o tamanho de heap do sistema não tenha limite superior, configure o tamanho inicial do heap do sistema para um valor que seja grande o bastante para acomodar a carga de trabalho usual de seu ambiente. Se a JVM ficar sem espaço de heap, ela emitirá chamadas para o gerenciador de memória do sistema operacional para obter espaço adicional. Essas chamadas utilizam recursos do sistema e podem impactar o desempenho.

    O produto inclui aproximadamente 8.000 classes. É possível utilizar esse número, juntamente com o tamanho médio dessas classes, para estimar um tamanho inicial para o heap do sistema. Se você souber quais classes são utilizadas por seus aplicativos, inclua tais classes no cálculo.

    [iSeries] Evitar Problemas: O i5/OS não suporta este argumento.gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -Xgpolicy

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

    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 como optthruput se você desejar otimizar o rendimento e isso não criar um problema se ocorrerem pausas longas de coleta de lixo. Esse é o parâmetro padrão, configuração recomendada.

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

    O Java SE 6 (Java Platform, Standard Edition 6) possui coleta de lixo de geração, que permite separar conjuntos de memórias para conter 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 conseguir um desempenho melhor, configure o tamanho do conjunto que contém objetos que possuem ciclos de vida curtos, de forma 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.

    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 de remanescentes. SurvivorRatio. Você pode utilizar as estatísticas de objetos coletadas pelo Tivoli Performance Viewer ou incluir o argumento verbose:gc em sua definição de configuração para monitorar as estatísticas de coleta de lixo. Se a coleta de lixo tornar-se um gargalo, especifique os seguintes argumentos para customizar as configurações do conjunto de geração de forma a ajustá-las melhor a seu ambiente.
    -XX:NewSize=lower_bound 
    -XX:MaxNewSize=upper_bound
     -XX:SurvivorRatio=new_ratio_size 
    Boas Práticas: Os valores padrão para esses argumentos são:NewSize=2m MaxNewSize=32m SurvivorRatio=2. Entretanto, se uma JVM estiver configurada com um tamanho de heap maior que 1 GB, utilize os valores: -XX:newSize=640m -XX:MaxNewSize=640m -XX:SurvivorRatio=16 ou configure 50 a 60 por cento do tamanho total de heap para um novo conjunto de geração. bprac
    [iSeries] Evitar Problemas: O i5/OS não suporta este argumento.gotcha
  • [AIX Solaris HP-UX Linux Windows] [z/OS] -Xminf

    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 de reconfiguração ativada, esse argumento especifica a porcentagem mínima de espaço livre para os heaps de middleware e temporários. O valor especificado para esse argumento é um número de vírgula flutuante, 0 a 1. O padrão é ,3 (30 por cento).

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

    O Java HotSpot Technology no Java SE 6 utiliza uma JVM adaptável contendo algoritmos que, com o decorrer do tempo, otimizam como o bytecode é desempenhado. A JVM é executada em dois modos, -server e -client. Na maioria dos casos, utilize o modo -server, que produz desempenho de tempo de execução mais eficiente por longos períodos de tempo.

    Se você utilizar o modo padrão -client, o tempo de inicialização do servidor será mais rápido e uma área de cobertura da memória menor será criada. 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 que o desempenho. Você pode 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.

    [iSeries] Evitar Problemas: O i5/OS não suporta este argumento.gotcha
  • -Dcom.ibm.CORBA.RequestTimeout=timeout_interval

    Esse argumento aplica-se apenas ao z/OS. Especifique o argumento -Dcom.ibm.CORBA.RequestTimeout= timeout_interval para configurar o tempo limite para responder a 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 esse argumento somente se seu aplicativo estiver encontrando problemas com tempos limites. Não há valores recomendados para esse argumento.

  • -Dcom.ibm.websphere.wlm.unusable.interval=interval

    Esse 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 do gerenciamento de carga de trabalho do cliente está sendo atualizado muito cedo ou muito tarde. Essa propriedade especifica, em segundos, o período de tempo que o tempo de execução do cliente de gerenciamento de carga de trabalho aguarda depois de marcar um servidor como indisponível, antes de tentar entrar em 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=

    Esse argumento aplica-se apenas ao z/OS. Especifique o argumento -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl= para indicar que o armazenamento para buffers de bytes diretos individuais deverá 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 bytes diretos, criados pela JVM para manipular dados do pedido, são alocados no heap de LE (Language Environment) em vez do heap de JVM. Geralmente, mesmo se os buffers de bytes diretos não forem mais necessários, a JVM não liberará esse armazenamento de LE nativo até que ocorra a próxima coleta de lixo. Se o servidor estiver manipulando pedidos grandes, o armazenamento LE poderá esgotar-se antes que a JVM execute um ciclo de coleta de lixo, fazendo com que o servidor seja encerrado de forma anormal. A configuração da JVM com o argumento a seguir impede que ocorram encerramentos anormais.
    -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl

    [z/OS] Na plataforma z/OS, você também precisará especificar esse argumento se especificar a propriedade customizada zaioFreeInitialBuffers para um canal TCP para permitir que o canal libere os buffers de leitura inicial utilizados em novas conexões quando esses buffers não foram mais necessários para a conexão.

  • [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 com o 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.

    Evitar Problemas:
    • [Solaris] [iSeries] [HP-UX] O IBM JVM para J2SE 5 não é suportado no Solaris, HP e i5/OS.
    • As classes de aplicativos J2EE em execução em um processo do servidor de aplicativos não são incluídas no cache de classes compartilhadas.
    gotcha
Tipo de Dados Cadeia
Unidades Argumentos da 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.

Tipo de Dados Cadeia
Unidades Nome do Caminho
Desativar JIT

Especifica se a opção do compilador JIT (Just-in-time) do código Java deve ser desativada.

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
Nome do sistema operacional

Especifica definições da JVM para um determinado sistema operacional.

Ao ser iniciado, o processo utiliza as configurações da JVM especificadas para o servidor como as configurações da JVM para o sistema operacional.

Ao ser iniciado, o processo utiliza as configurações da JVM especificadas para o nó como as configurações da JVM para o sistema operacional.

Guia Tempo de Execução

Coleta de Lixo Detalhada

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.

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

,

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.

Você pode verificar o relatório verboseGC para determinar:
  • Quanto tempo a JVM está gastando para desempenhar a coleta de lixo.
    De modo ideal, você deseja que a JVM gaste menos de 5 por cento de seu tempo de processamento para desempenhar a coleta de lixo. Para determinar a porcentagem de tempo que a JVM gasta na coleta de lixo, divida o tempo que ela levou para concluir a coleta pelo período de tempo desde o último AF e multiplique o resultado por 100. Exemplo:
    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 que esteja ocorrendo com freqüência, pode ser necessário aumentar o tamanho de heap 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 fica desalocada após cada ciclo de coleta de lixo e verifique se a porcentagem não está continuando a declinar. Se a porcentagem de espaço livre continuar seu declínio, significa que está havendo um aumento gradual no tamanho de heap de uma coleta de lixo para outra. Essa situação pode indicar uma fuga de memória no aplicativo.

[z/OS] Na plataforma z/OS, também é possível emitir o comando do 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 do heap da JVM também é disponibilizado para o PMI e pode ser monitorado utilizando-se o Tivoli Performance Viewer.




Links marcados (on-line) requerem acesso à Internet.

Tarefas relacionadas
Referências relacionadas
Coleção de Propriedades Customizadas
[AIX Solaris HP-UX Linux Windows]


Nome do arquivo: urun_rconfproc_jvm.html