Usando a coleta de lixo detalhada para analisar as questões de memória do IBM WebSphere Portal

Saiba como ler a coleta de lixo detalhada e usar a ferramenta para analisar as questões de memória do servidor IBM® WebSphere® Portal. Este artigo é específico para versões 6.0 e 5.1 (ou posteriores) do WebSphere Portal, executando o Java™ Software Development Kit (SDK) 1.4.2.

Matt Munse, Support Engineer, IBM

Matt Munse é engenheiro de suporte e dá ênfase a problemas do tempo de execução do WebSphere Portal, incluindo memória, interrupções, travamentos, desempenho e problemas do mecanismo de pesquisa do WebSphere Portal, desde 2002. Além de atuar como ponto focal de suporte para problemas de desempenho do WebSphere Portal Server, ele contribui para que a IBM patenteie e desenvolva aplicativos Java e J2EE para uso interno. É possível entrar em contato com Matt em msmunse@us.ibm.com.



16/Abr/2010

Nota do editor: Conhece muito sobre esse tópico? Deseja compartilhar seu conhecimento? Participe hoje do programa de wiki do software IBM Lotus.

Introdução à coleta de lixo

NOTA: Para obter o ajuste apropriado, use o último release de serviço do SDK ou, pelo menos, uma versão de serviço posterior à SR13, para conseguir o ajuste discutido aqui.

Uma definição simples de coleta de lixo é o ato da JavaTM Virtual Machine (JVM) percorrer o heap (uma seção definida da memória usada para gerenciamento de recursos em um aplicativo Java) dos objetos que não estão mais incluídos em referências nem são usados pelo processo.

O processo tem três fases principais: marcação, varredura e compactação:

  • Na fase de marcação, todos os objetos no heap são "marcados" com um bit. Há uma verificação para confirmar se ainda há alguma referência para eles. Em caso afirmativo, o bit é removido.
  • Na fase de varredura, a JVM percorre o heap e remove todos os objetos que ainda apresentam o bit de marcação; esses objetos não constam mais de nenhuma referência, nem são mais usados.
  • A fase de compactação é executada apenas em uma GC completa, que tenta realocar todos os objetos no heap para um espaço menor, mais compacto e mais contíguo.

Como a coleta de lixo funciona

O melhor modo de inspecionar o uso do heap é analisar a saída da GC detalhada.

O primeiro passo é assegurar que a GC detalhada esteja ativada no servidor:

  1. No console administrativo do IBM WebSphere Application Server, navegue até Application Servers - WebSphere_Portal - Java and Process Management - Process Definition - Java Virtual Machine.
  2. Assegure-se de que a caixa de seleção ao lado de Verbose garbage collection esteja selecionada e reinicie o servidor.
  3. Agora, você verá uma entrada similar ao registro abaixo, no arquivo native_stderr.log:
    <AF[177]: Allocation Failure. need 528 bytes, 3602594 ms since last AF>
    <AF[177]: managing allocation failure, action=1 (0/585421800) (29966688/30811672)>
    <GC(177): GC cycle started Fri Sep 21 23:48:29 2007
    <GC(177): freed 218620376 bytes, 40% free (248587064/616233472), in 459 ms>
    <GC(177): mark: 422 ms, sweep: 37 ms, compact: 0 ms>
    <GC(177): refs: soft 0 (age >= 32), weak 11, final 7424, phantom 0>
    <AF[177]: completed in 460 ms>

Analisando as entradas do arquivo de log

Agora, vamos desmembrar a entrada de log precedente em partes e determinar o que ela nos informa.

Comecemos por aqui:

<AF[177]: Allocation Failure. need 528 bytes, 3602594 ms since last AF>

Quando não há espaço contíguo suficiente no heap para alocar o objeto, esta entrada nos permite saber se houve alguma falha de alocação. Esse objeto é a ação mais comum que você pode ver na saída da coleta de lixo detalhada. Neste caso, foi um objeto pequeno de 528 bytes.

Também é possível ver nessa linha que houve um intervalo de tempo desde a última execução de ciclo de GC, de 3602594 ms.

Em seguida, examinemos a última linha:

<AF[177]: completed in 460 ms>

Ela mostra a quantidade de tempo gasta na GC. Com esse número, é possível obter a proporção da última vez que estivemos na GC e descobrir a porcentagem de tempo que gastamos fazendo GC, em vez de trabalho real, por exemplo:

460/3602594 = .000127% of the time was spent in GC

Em um servidor íntegro, menos de 13 % (o ideal é cerca de 7 a 10 %) do tempo deve ser gasto em GC.

Retorne à segunda linha:

<AF[177]: managing allocation failure, action=1 (0/585421800) (29966688/30811672)>

A primeira coisa a observar aqui é o dado “action=”. Podem ocorrer sete ações diferentes para uma falha de alocação:

  • action=0 significa que pinnedFreeList estava esgotada.
  • action=1 significa um ciclo de coleta de lixo preemptivo.
  • action=2 significa uma falha de alocação total.
  • action=3 significa que ocorre uma expansão de heap.
  • action=4 significa que todas as referências parciais conhecidas são apagadas.
  • action=5 significa que a apropriação do heap temporário é feita.
  • action=6 significa que o espaço livre está muito baixo.

Essas ações são listadas por ordem de gravidade, a mais grave ocorre quando o servidor está totalmente sem memória (action=6).

Neste caso, temos a action=1. Neste tipo de GC, apenas as fases de marcação e varredura são executadas.

Essa linha também inclui:

(0/585421800) (29966688/30811672)

Essa linha é específica das JVMs do AIX®. Como é possível ver, há dois números básicos que, quando adicionados em conjunto, são do tamanho para o qual o heap foi expandido. Um é menor e é usado automaticamente para alocação de objeto grande.

NOTA: Um objeto grande é algo com mais de 64 K.

Todos os outros objetos são colocados na outra seção do heap. Se a seção de objeto grande for preenchida com outra alocação de pedidos de objeto grande, o objeto será colocado na outra seção principal do heap. Esse objeto pode ser um parâmetro de ajuste útil em outras JVMs de multiplataforma e chamado de -Xloratio.

A seguinte linha é:

<GC(177): GC cycle started Fri Sep 21 23:48:29 2007

Essa linha informa o horário em que o ciclo de GC iniciou e o ciclo em que estava, ou seja, GC(177). Essa é a 177a vez que a GC foi executada desde que a JVM foi iniciada.

A linha a seguir:

<GC(177): freed 218620376 bytes, 40% free (248587064/616233472), in 459 ms>

denota quantos bytes foram liberados durante o ciclo de GC; neste caso, a JVM foi capaz de liberar 218620376 bytes.

Além disso, vemos que o heap está agora 40% livre e que há 248.587.064 bytes livres no tamanho do heap de 616.233.472 bytes:

(248587064/616233472)

Finalmente, o ciclo de GC levou 459 ms para ser concluído.

Essa linha é útil porque ela informa a quantidade de heap livre e que há objetos que estão sendo limpos e não estão fixados no heap.

A seguinte linha é:

<GC(177): mark: 422 ms, sweep: 37 ms, compact: 0 ms>

Essa linha será útil mais tarde, neste artigo, para ajustar como configurar a GC a fim de executar mais rápido (consulte -Xgcpolicy:optavgpause), mas, por ora, basta compreender:

Esta linha mostra por quanto tempo o ciclo está em execução. A fase de marcação levou 422 ms, a fase de varredura, 37 ms, e a fase de compactação, 0 ms.

Além disso, duas coisas informam que essa não é uma GC completa:

  • A fase de compactação levou 0 ms para ser concluída.
  • A action=1 mostra que ela era uma GC preemptiva, antes que uma GC completa seja executada.

A última linha a ser estudada é:

<GC(177): refs: soft 0 (age >= 32), weak 11, final 7424, phantom 0>

Primeiro, é necessário compreender que a GC não apenas gerencia objetos, mas mantém um objeto de referência separado para o objeto real. Essas referências são associadas a uma das quatro filas na criação e essa associação não pode ser alterada posteriormente. As quatro filas são marcadas durante a fase de marcação, nesta ordem:

  1. Soft
  2. Weak
  3. Final
  4. Phantom

As referências soft e weak poderão ser limpas quando não mais constarem de nenhuma referência. Se um finalizador (uma fila Final) estiver associado a uma referência soft ou weak, apenas depois da remoção de tal referência o finalizador será removido, na próxima passagem da GC a ser executada.

Essas são as linhas principais que podem ser vistas na política de GC padrão em um Java SDK 1.4.2. Com esse entendimento, vamos explorar como uma JVM executa.


Ciclo de vida da JVM

A JVM inicia com argumentos de linha de comandos opcionais que iniciam o processo. Estes são os argumentos JVM genéricos que foram adicionados no console administrativo do WebSphere Application Server.

Em um nível básico, este é o comando executado quando o processo Java é iniciado:

Java –Xmx1024M –Xms256M –Xverbosegc programToRun

onde os argumentos da linha de comando

–Xmx1024M –Xms256M –Xverbosegc

significam que ocorre o seguinte na inicialização:

  • O tamanho máximo do heap é 1024 M (–Xmx1024M)
  • O tamanho mínimo do heap é 256 M (–Xms256M)
  • É usada a coleta de lixo detalhada (–Xverbosegc)

É importante observar que, embora tenhamos alocado 1024 M para a JVM, como fizemos no fragmento de GC detalhado acima, isso não significa que sempre usamos ou usaremos o total de 1024 M. Por exemplo, no fragmento detalhado, usamos apenas 616.233.472 bytes.

A JVM inicia com o mínimo de 256 M alocado e coloca esse espaço em uso. Como ilustrado na figura 1, neste caso, o heap total, 1024 M, está separado para uso (a barra inteira), mas apenas o espaço inicial de 256 M está alocado para ser usado, conforme mostrado pela área sombreada.

Figura 1. Representação pictórica do heap
Representação pictórica do heap

Como há 256 M disponíveis, a JVM começa a ocupar tal espaço inicial com os objetos necessários para executar o programa programToRun. Os objetos serão adicionados a esse espaço até que não haja espaço contíguo suficiente para atender ao pedido para o próximo objeto a ser colocado no heap (veja a figura 2).

Figura 2. Heap com objetos de tamanhos diferentes carregados
Heap com objetos de tamanhos diferentes carregados

O próximo objeto agora solicita espaço no heap, mas não há espaço contíguo suficiente para atender ao pedido (veja a figura 3).

Figura 3. Representação pictórica do pedido do objeto
Representação pictórica do pedido do objeto

Quando esse pedido acontece, a JVM executa uma GC com a action=1 e as representações pictóricas mudam como mostrado na figura 4.

Figura 4. JVM executando a GC com action=1 (observe que o objeto não utilizado é removido)
JVM executando a GC com action=1 (observe que o objeto não utilizado é removido)

Torna-se:

Desse modo, o pedido pode ser atendido agora:

Às vezes, há objetos que não podem ser movidos ou limpos; a saber, objetos de classe e objetos que ainda estão em uso. Digamos que haja dois pedidos idênticos ao do caso anterior, contudo, agora nenhum objeto no heap pode ser removido (veja a figura 5).

Figura 5. Representação atual do heap em uso
Representação atual do heap em uso

Nesse caso, a GC executa uma action=2, que tenta executar uma fase de compactação. Em uma fase de compactação, os objetos que estão no heap são consolidados de modo a permitir a obtenção de qualquer memória livre e satisfazer o pedido atual.

A representação pictórica do heap torna-se como ilustrada na figura 6.

Figura 6. Heap compactado
Heap compactado

A esta altura, o próximo pedido pode ser alocado (veja a figura 7).

Figura 7. O progresso do heap em operação continua
O progresso do heap em operação continua

Agora que as ações 1 e 2 da GC foram entendidas, nós podemos ver o que acontece quando não há espaço suficiente para alocar o próximo objeto, mesmo depois da execução das ações 1 e 2.

Essa falta de espaço será o caso se continuarmos com nosso heap porque partimos da premissa de que nem todos os objetos podem ser limpos (consulte a figura 8).

Figura 8. Heap compactado com o espaço total alocado
Heap compactado com o espaço total alocado

É possível ver que a quantidade de heap que estamos usando é a total. Em nosso exemplo, temos 256 M de heap total e alocamos apenas 256 M como heap utilizável, até o momento. Não se esqueça de que o tamanho máximo do heap está definido como 1024 M, assim temos mais a que recorrer se essa situação vier a ocorrer.

Nesse caso, a JVM conduz uma action=3 e expande o heap até 65.535 bytes para proporcionar mais heap para ser usado (veja a figura 9); esse caso será visto na GC detalhada.

Figura 9. Heap do sistema expandido até 65536 bytes
Heap do sistema expandido até 65536 bytes

Torna-se isto:

E, agora, o processamento pode continuar. O ciclo de GC continuará até que todo o heap recém-alocado passe pelas mesmas ações acima e mais heap seja alocado até que, por fim, os 1024 M totais serão atingidos.

Como é possível ver com esse método, o heap inicial é pequeno, cresce sequencialmente e permanece compacto e relativamente íntegro.

Este é um exemplo de uma GC detalhada a partir de uma GC total, seguida por uma expansão de heap:

<AF[12]: Allocation Failure. need 8208 bytes, 2272 ms since last AF>
<AF[12]: managing allocation failure, action=2 (3255768/52427264)>
  <GC(12): GC cycle started Wed Dec  2 13:55:07 2009
  <GC(12): freed 9836696 bytes, 24% free (13092464/52427264), in 59 ms>
  <GC(12): mark: 50 ms, sweep: 8 ms, compact: 1 ms>
  <GC(12): refs: soft 0 (age >= 32), weak 0, final 102, phantom 0>
<AF[12]: managing allocation failure, action=3 (13092464/52427264)>
  <GC(12): need to expand mark bits for 61602304-byte heap>
  <GC(12): expanded mark bits by 143360 to 962560 bytes>
  <GC(12): need to expand alloc bits for 61602304-byte heap>
  <GC(12): expanded alloc bits by 143360 to 962560 bytes>
  <GC(12): need to expand FR bits for 61602304-byte heap>
  <GC(12): expanded FR bits by 286720 to 1925120 bytes>
  <GC(12): expanded heap by 9175040 to 61602304 bytes, 36% free>
<AF[12]: completed in 75 ms>

Agora que você compreendeu como o heap cresce e é usado pela JVM, pode compreender melhor a quantidade de memória que está sendo realmente usada pela JVM enquanto o processo está em execução.


Analisando a quantidade de memória usada por um processo

Pode haver erros sobre a quantidade de memória que um processo ou portal usa durante o tempo de execução. Muitas vezes, os usuários do portal determinam a quantidade de memória que o processo Java está usando por meio do comando ps avg ou pelo Gerenciador de Tarefas do Microsoft® Windows®, que mostram quanta memória foi alocada para o processo Java.

Como vimos, apenas porque a quantidade de memória X está alocada para o processo, isso não significa que todo X está sendo usado.

Se o Gerenciador de Tarefas ou “ps avg” mostrar que o processo Java está usando 616 M e examinarmos a GC detalhada, veremos que ela está usando, atualmente, apenas 40% dessa quantidade:

<GC(177): freed 218620376 bytes, 40% free (248587064/616233472), in 459 ms>

OUTOFMEMORY error with free space in the heap

Se você receber um erro de OUTOFMEMORY e houver espaço livre no heap, poderá examinar a GC detalhada para determinar o que causou isso. Este é um exemplo de saída de uma ocorrência de falta de memória na GC detalhada:

<AF[2474]: Allocation Failure. need 16777232 bytes, 114 ms since lastAF>
<AF[2474]: managing allocation failure, action=2(1026078032/1601894912)>
  <GC(2835): GC cycle started Thu Jul 16 11:21:34 2009
  <GC(2835): freed 5827392 bytes, 64% free (1031905424/1601894912), in 2519 ms>
  <GC(2835): mark: 567 ms, sweep: 24 ms, compact: 1928 ms>
  <GC(2835): refs: soft 0 (age >= 32), weak 0, final 6, phantom 0>
  <GC(2835): moved 1711341 objects, 87482984 bytes, reason=1, used 8 more bytes>
<AF[2474]: managing allocation failure, action=3 (1031905424/1601894912)>
  <GC(2835): need to expand mark bits for 1610611200-byte heap>
  <GC(2835): expanded mark bits by 135168 to 25165824 bytes>
  <GC(2835): need to expand alloc bits for 1610611200-byte heap>
  <GC(2835): expanded alloc bits by 135168 to 25165824 bytes>
  <GC(2835): need to expand FR bits for 1610611200-byte heap>
  <GC(2835): expanded FR bits by 270336 to 50331648 bytes>
  <GC(2835): expanded heap fully by 8716288 to 1610611200 bytes, 64% free>
<AF[2474]: managing allocation failure, action=4 (1040621712/1610611200)>
<AF[2474]: clearing all remaining soft refs>
  <GC(2836): GC cycle started Thu Jul 16 11:21:35 2009
  <GC(2836): freed 227346312 bytes, 78% free (1267968024/1610611200), in 1600 ms>
  <GC(2836): mark: 370 ms, sweep: 19 ms, compact: 1211 ms>
  <GC(2836): refs: soft 438 (age >= 32), weak 1178, final 70, phantom 0>
  <GC(2836): moved 1359393 objects, 60973368 bytes, reason=1, used 600 more bytes>
<AF[2474]: managing allocation failure, action=6 (1267968024/1610611200)>
JVMDG217: Dump Handler is Processing OutOfMemory - Please Wait.
JVMDG315: JVM Requesting Heap dump file
JVMDG318: Heap dump file written to
/opt/WebSphere/AppServer/heapdump.20090716.112135.19377.phd
JVMDG303: JVM Requesting Java core file
JVMDG304: Java core file written to
/opt/WebSphere/AppServer/javacore.20090716.112144.19377.txt
JVMDG274: Dump Handler has Processed OutOfMemory.
<AF[2474]: Insufficient space in Javaheap to satisfy allocation request>
<AF[2474]: completed in 19738 ms>

Como vimos, há muita memória livre nesta instância:

<GC(2836): freed 227346312 bytes, 78% free (1267968024/1610611200), in 1600 ms>

mas o objeto que está solicitando espaço de alocação também era muito grande:

<AF[2474]: Allocation Failure. need 16777232 bytes, 114 ms since lastAF>

Há dois modos para combater esse tipo de situação de falta de memória, quer com um k-cluster (-Xk), quer definindo um segmento do heap para objetos grandes (–Xloratio), onde loratio é a proporção de objeto grande.

-Xkn

Este parâmetro separa um espaço no heap para armazenamento de objetos de classe. Como vimos no exemplo anterior, as referências que ainda estão em uso pelo processo não podem ser movidas ou limpas. Elas foram “fixadas” nesse local do heap e, se objetos suficientes forem fixados em locais diferentes no heap, este se torna fragmentado.

Para corrigir essa fragmentação, é possível usar o parâmetro –Xkn, que fornece uma seção do heap exclusivamente para objetos de classe. Um bom valor inicial para n nesse parâmetro é 40.000, embora você tenha de envolver o WebSphere Portal Support para análise do ajuste do sistema.

Se definirmos esse parâmetro em 40.000, a JVM permitirá espaço para que 40.000 objetos de classe sejam armazenados no k-cluster. Se o k-cluster ficar cheio, o sistema continuará como normal e usará o restante do heap para o processamento.

Para adicionar o –Xk aos argumentos JVM genéricos no console administrativo, siga estas etapas:

  1. No WebSphere Application Server V6.0, selecione Servers - Application Servers - nome_do_servidor - Java and Process Management - Process definition - Java Virtual Machine - Generic JVM Arguments.

    Ou

    No WebSphere Application Server V5.0 e V5.1, selecione Servers - Application Servers - nome_do_servidor - Process Definition - Java Virtual Machine - Generic JVM Arguments.
  2. Insira –Xk40000, salve essa configuração e reinicie o servidor.

–Xloration

Esta configuração permite que uma seção do heap seja separada para uso de grandes objetos, definidos como maiores de 64 K.

Como vimos no exemplo com representações pictóricas, um objeto precisa de espaço contíguo para ser alocado no heap. Obviamente, é mais fácil localizar 528 bytes de espaço contíguo do que 1.000.000 bytes de espaço contíguo.

Se forem mantidos grandes objetos dentro de determinado segmento do heap, eles poderão ser mais facilmente alocados; ademais, objetos menores não precisarão competir com eles para obter a utilização do heap.

O valor desse parâmetro é algo que pode ser ajustado monitorando a GC detalhada depois da implementação. O valor n deste parâmetro é obtido como uma porcentagem do heap total que está expandido neste momento. Para este exemplo, vamos usar o valor –Xloratio0.2.

Quando esse valor é adicionado ao servidor, você vê uma nova linha adicionada à saída de GC detalhada, por exemplo:

<GC(2): heap layout: (424744560/429495496) (107373880/107373880) /0>

Abaixo está um bloco da GC detalhado com a –Xloratio0.2 ativada:

<AF[2]: Allocation Failure. need 536 bytes, 235 ms since last AF>
<AF[2]: managing allocation failure, action=0 (423162736/429495496) 
(107373880/107373880)>
  <GC(2): GC cycle started Sat Aug 15 17:07:25 2009
  <GC(2): heap layout:  (424744560/429495496) (107373880/107373880)  /0>
  <GC(2): freed 1581824 bytes, 99% free (532118440/536869376), in 18 ms>
  <GC(2): mark: 9 ms, sweep: 9 ms, compact: 0 ms>
  <GC(2): refs: soft 0 (age >= 32), weak 0, final 0, phantom 0>
<AF[2]: completed in 18 ms>

Essa linha é como podemos ajustar o valor de n, já que é possível, agora, visualizar o layout do heap:

<GC(2): heap layout: (424744560/429495496) (107373880/107373880) /0>

A primeira proporção é a área normal do heap (80% usada para processamento normal) e a segunda é o que definimos para grandes objetos (20% para alocação de grandes objetos).

O que é exibido é a quantidade de espaço livre em cada seção. Como vimos nessa saída, toda seção de objetos grandes está livre, e não há nenhum objeto grande em uso.

Se essa tendência continuar, diminuiremos a fração de 20 para 10%, a fim de permitir que mais espaço seja usado para processamento normal. Usamos o –Xloratio0.1 para o novo valor, um bom valor com o qual começar é 10% ou 0,1.)

Para adicionar o –Xloratio aos argumentos JVM genéricos no console administrativo, siga estas etapas:

  1. No WebSphere Application Server V6.0, selecione Servers - Application Servers - nome_do_servidor - Java and Process Management - Process definition - Java Virtual Machine - Generic JVM Arguments.

    Ou

    No WebSphere Application Server V5.0 e V5.1, selecione Servers - Application Servers - nome_do_servidor - Process Definition - Java Virtual Machine - Generic JVM Arguments.
  2. Insira –Xloratio0.1, salve essa configuração e reinicie o servidor.

Ajuste adicional para Java SDK 1.4.2

Vários processadores

É possível usar mais de um encadeamento para executar a GC. Este número é um a menos do que o número de processadores que você tem no sistema, por exemplo, se tiver um sistema de quatro processadores, use três encadeamentos para GC. Para obter esse valor, implementamos o seguinte parâmetro:

–Xgcthreadsn
Para definir três encadeamentos em um sistema de quatro processadores, adicione o parâmetro –Xgcthreads aos argumentos JVM genéricos no console administrativo; siga estas etapas:

  1. No WebSphere Application Server V6.0, selecione Servers - Application Servers - nome_do_servidor - Java and Process Management - Process definition - Java Virtual Machine - Generic JVM Arguments.

    Ou

    No WebSphere Application Server V5.0 e V5.1, selecione Servers - Application Servers - nome_do_servidor - Process Definition - Java Virtual Machine - Generic JVM Arguments.
  2. Insira –Xgcthreads3, salve essa configuração e reinicie o servidor.

Pós-SR12

Outra coisa que você pode fazer para ajudar com o desempenho de GC é ativar um parâmetro de marcação concorrente. Como vimos com o monitoramento da saída de GC detalhada, a maioria do tempo gasto ocorre na fase de marcação do ciclo de GC. Por exemplo:

<AF[1640]: Allocation Failure. need 536 bytes, 154266 ms since last AF>
<AF[1640]: managing allocation failure, action=1 (0/879124880) 
(215122200/219781232)>
  <GC(1718): GC cycle started Wed Aug 19 13:16:24 2009
  <GC(1718): heap layout:  (308539208/879124880) (215136552/219781232)  /0>
  <GC(1718): freed 308553560 bytes, 47% free (523675760/1098906112), 
  in 684 ms>
  <GC(1718): mark: 607 ms, sweep: 77 ms, compact: 0 ms>
  <GC(1718): refs: soft 1 (age >= 32), weak 19, final 582, phantom 3>
<AF[1640]: completed in 685 ms>

Aqui, 607 ms do total de 685 ms foram gastos em marcação. Para combater esse tempo gasto, você pode introduzir o seguinte parâmetro, fornecido para trabalhar corretamente nas versões SR13 e posteriores do JDK:

–Xgcpolicy:optavgpause
O parâmetro reduzirá o tempo gasto em marcação e manterá a fase de marcação em execução, mesmo se um ciclo de GC não estiver em processamento.

Para adicionar o parâmetro –Xgcpolicy:optavgpause aos argumentos JVM genéricos no console administrativo (SR13 e posterior do Java SDK 1.4.2), siga estas etapas:

  1. No WebSphere Application Server V6.0, selecione Servers - Application Servers - nome_do_servidor - Java and Process Management - Process definition - Java Virtual Machine - Generic JVM Arguments.

    Ou

    No WebSphere Application Server V5.0 e V5.1, selecione Servers - Application Servers - nome_do_servidor - Process Definition - Java Virtual Machine - Generic JVM Arguments.
  2. Insira –Xgcpolicy:optavgpause, salve essa configuração e reinicie o servidor.

Conclusão

Agora, você deve compreender como ler a coleta de lixo detalhada e como usar essa ferramenta para analisar e resolver os problemas de memória do WebSphere Portal Server.

Recursos

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=WebSphere
ArticleID=483367
ArticleTitle=Usando a coleta de lixo detalhada para analisar as questões de memória do IBM WebSphere Portal
publish-date=04162010