É possível digitar os seguintes argumentos opcionais da linha de comando no campo
. Se você digitar mais de um argumento, digite um espaço entre cada argumento.
![[z/OS]](../ngzos.gif)
![[AIX Solaris HP-UX Linux Windows]](../dist.gif)
-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. Portanto, o serviço
não precisa executar uma comparação completa do repositório quando o gerenciador de
implementação ou os servidores de 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.
![[8.5.0.1 or later]](../images/ng_v8501.gif)
-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 and 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.
- -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: 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![[IBM i]](../iseries.gif)
Evitar Problemas: IBM i não suporta este argumento.
gotcha
- -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: - 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 não suporta este argumento.
gotcha
- -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: O impacto de desempenho da coleta de lixo de classe normalmente é mínima e desativar
a coleta de lixo de classe em um sistema baseado no Java Platform Enterprise
Edition (Java EE), que sobrecarrega o uso dos carregadores de classe de aplicativo,
pode efetivamente causar uma fuga de memória dos dados de classe e fazer com que
a JVM emita uma 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, deve sempre reiniciar o servidor de aplicativos para
limpar as classes e dados estáticos da versão anterior do aplicativo.
Evitar Problemas: IBM i não suporta este argumento. Você deve usar o
argumento
-noclassgc para desativar a coleta de lixo da classe nesta plataforma.
gotcha
- -Xgcthreads
Especifique -Xgcthreads, se
desejar utilizar vários encadeamentos de coleta de lixo de uma vez. 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.
Especifique
-Xgcthreads da seguinte forma:
-Xgcthreads<number of processors>
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: Você
deve utilizar a coleta de lixo paralela, se sua máquina tiver mais de um processador.
bprac
Evitar Problemas: IBM i não suporta este argumento.
gotcha
- -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 você estiver usando 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.
Evitar Problemas: IBM i não suporta este argumento.
gotcha
- -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 ![[Updated in September 2013]](../images/delta.gif)
se desejar otimizar o rendimento, e ele não
criará um problema se ocorrer uma pausa na coleta de lixo longa.![[Updated in September 2013]](../images/deltaend.gif)
Configure esse argumento como gencon,
se estiver usando um coletor de lixo de geração. O esquema de
geração tenta atingir um alto rendimento juntamente com tempos de pausa
reduzidos de coleta de lixo. 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. No entanto, utilizar esta política reduz o rendimento porque os encadeamentos podem precisar executar trabalho extra.
Configure esse argumento como subpool,
se quiser aumentar o desempenho em sistemas de multiprocessador, que
usam, em geral, mais de oito processadores. Essa política está disponível apenas 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: IBM i não suporta este argumento.
gotcha
- -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 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. É possível usar as estatísticas do objeto que o Tivoli Performance Viewer coleta, 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: 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: IBM i não suporta este argumento.
gotcha
- -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: IBM i não suporta este argumento.
gotcha
- -server | -client
O Java HotSpot Technology no Java SE 6 usa uma JVM adaptável que contém algoritmos que, ao longo do tempo, otimizam o modo 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. 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: IBM i não suporta este 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 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 este argumento.
- -Dcom.ibm.server.allow.sigkill=true
O argumento -Dcom.ibm.server.allow.sigkill=true permite que o processo do agente do nó use o método terminar de um processo quando o método parar não é concluído dentro do intervalo de tempo especificado para o intervalo de ping. Essa configuração é útil quando o agente do nó está monitorando um servidor de aplicativos e perde o contato com esse servidor de aplicativos.
Quando a política de monitoramento do servidor de aplicativos permite que o agente do nó reinicie o servidor de aplicativos, pois a reinicialização automática está ativada para o servidor de aplicativos, o agente do nó executa o método parar no processo do servidor de aplicativos. Durante o processamento da parada, o agente do nó monitora 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 terminar no processo do servidor de aplicativos para pará-lo.
Se você configurar esse argumento como false, o agente do nó continuará monitorando o processo de parada, mas não tentará reiniciar 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 somente sob a direção da equipe de suporte IBM.
- -Dcom.ibm.websphere.wlm.unusable.interval=interval
Esse argumento se aplica 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.
- -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=
Esse argumento se aplica 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.
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 coleta de lixo. Se o servidor estiver manipulando
grandes pedidos, o armazenamento do LE pode se esgotar antes que a JVM execute
um ciclo de coleta 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
Na plataforma z/OS, também é necessário especificar esse argumento se você especificar a propriedade customizada zaioFreeInitialBuffers para um canal TCP para que o canal libere os buffers de leitura iniciais usados em novas conexões assim que esses buffers não forem mais necessários para a conexão.
- -DisSipComplianceEnabled=true|false
Especifica
se a verificação de conformidade de SIP está ativada no servidor proxy SIP.
A verificação de conformidade de SIP assegura que as mensagens de SIP estão
em conformidade com o padrão do Session Initiation Protocol. Quando essa propriedade é configurada
como true, a verificação de conformidade de SIP é ativada.
Evitar Problemas: Se você estiver executando um servidor proxy em um ambiente do z/OS
WebSphere Application Server, Network Deployment, e o servidor proxy não fizer parte de um cluster, poderá usar a propriedade customizada do servidor proxy SIP isSipComplianceEnabled para ativar ou desativar a verificação de conformidade do 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
- -Xshareclasses:none
Especifique o argumento -Xshareclasses:none
para desativar a opção de classes de compartilhamento para um processo. A opção de classes de compartilhamento, que está disponível com o 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.
Nota: Ao
usar clearclasscache, para limpar o cache inteiro, você deve parar todas as
JVMs conectadas.
Evitar Problemas: ![[Solaris]](../solaris.gif)
![[HP-UX]](../hpux.gif)
A IBM JVM para J2SE 5 não é suportada no
Solaris, no HP e no IBM i.- As classes do aplicativo Java EE em execução em um processo do servidor de aplicativos não são incluídas no cache de classe compartilhada.
gotcha
- -XXallowvmshutdown:false
Utilize o argumento
-XXallowvmshutdown:false para reverter para um comportamento anterior
para a JVM que não está correta.
O Java 5.0 SR10 e o Java 6 SR5 corrigem problemas nos quais a Java virtual machine (JVM) não é encerrada 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.
Para Usuários de Transição: