Ajustando as Java virtual machines

Você deve levar em conta vários aspectos específicos do ajuste da Java Virtual Machine (JVM) para melhorar o desempenho do WebSphere eXtreme Scale. Na maioria dos casos, poucas ou nenhuma configuração da JVM é necessária. Se muitos objetos estiverem sendo armazenados na grade de dados, ajuste o tamanho de heap para um nível apropriado a fim de evitar execução sem memória.

Ao configurar o eXtremeMemory, é possível armazenar os objetos na memória nativa em vez de armazenar no heap Java. Configurar o eXtremeMemory ativa o eXtremeIO como um novo mecanismo de transporte. Movendo objetos para fora do heap Java, é possível evitar pausas da coleta de lixo, levando ao desempenho mais constante e tempos de resposta atribuíveis. Para obter informações adicionais, consulte Configurando o IBM eXtremeMemory e o IBM eXtremeIO.

Plataformas Testadas

Os testes de desempenho ocorreram principalmente no AIX (32 vias), Linux (quatro vias) e computadores Windows (oito vias). Com computadores AIX sofisticados, é possível testar fortemente cenários multiencadeados para identificar e corrigir os pontos de contenção.

Coleta de Lixo

O WebSphere eXtreme Scale cria objetos temporários associados a cada transação, como pedido e reposta e sequência de log. Como esses objetos afetam a eficiência da coleta de lixo, o ajuste da coleta de lixo é fundamental.

Todas as JVMs modernas usam algoritmos de coleta de lixo paralela, o que significa que o uso de mais núcleos pode reduzir pausas na coleta de lixo. A coleta de lixo em um servidor físico com oito núcleos é mais rápida do que em um servidor físico com quatro núcleos.

Quando o aplicativo deve gerenciar uma grande quantidade de dados para cada partição, a coleta de lixo pode ser um fator. Na maioria das vezes, um cenário de leitura tem um bom desempenho mesmo com heaps grandes (20 GB ou mais) se um coletor geracional é utilizado. Contudo, depois que o heap de estabilidade é preenchido, ocorre uma pausa proporcional ao tamanho do heap ativo e ao número de processadores no computador. Essa pausa pode ser maior ou menor em máquinas com grandes heaps.

Máquina Virtual IBM para Coleta de Lixo Java

Para a máquina virtual IBM® para Java, use o coletor optavgpause para cenários com alta taxa de atualização (100% das entradas de modificação de transações). O coletor gencon funciona muito melhor que o coletor optavgpause nos cenários em que os dados são atualizados relativamente com pouca frequência (10% do tempo ou menos). Experimente ambos os coletores para ver qual funciona melhor no seu cenário. Executar com a coleta de lixo detalhada ativada para verificar a porcentagem de tempo gasto na coleta de lixo. Ocorreram cenários em que 80% do tempo foi gasto na coleta de lixo até que um que o ajuste resolvesse o problema.

Use o parâmetro -Xgcpolicy para alterar o mecanismo de coleta de lixo. O valor do parâmetro -Xgcpolicy pode ser configurado como: -Xgcpolicy:gencon ou -Xgcpolicy:optavgpause, dependendo de qual coletor de lixo você deseja usar.

Outras Opções de Coleta de Lixo

Atenção: Se você estiver usando um Oracle JVM, podem ser necessários ajustes na coleta de lixo padrão e na política de ajuste.

O WebSphere eXtreme Scale suporta o WebSphere Real Time Java. Com o WebSphere Real Time Java, a resposta de processamento de transação do WebSphere eXtreme Scale é mais consistente e previsível. Como resultado, o impacto da coleta de lixo e do planejamento do encadeamento é enormemente minimizado. O impacto é reduzido ao nível no qual o tempo de desvio de resposta padrão é inferior a 10% da Java regular.

Desempenho da JVM

O WebSphere eXtreme Scale pode ser executado em versões diferentes do Java Platform, Standard Edition. O WebSphere eXtreme Scale suporta o Java SE Versão 5, o Java SE Versão 6 e o Java SE Versão 7. Para obter uma produtividade e desempenho melhorados do desenvolvedor, use Java SE Versão 5, Versão 6, ou Java SE Versão 7 para aproveitar as anotações e a coleta de lixo melhorada. O WebSphere eXtreme Scale funciona em Java virtual machines de 32 ou 64 bits.

O WebSphere eXtreme Scale é testado com um subconjunto das máquinas virtuais disponíveis, todavia, a lista suportada não é exclusiva. É possível executar o WebSphere eXtreme Scale em qualquer JVM do fornecedor na Edição 5 ou posterior. No entanto, se ocorrer um problema com uma JVM do fornecedor, você deverá contatar o fornecedor da JVM para obter suporte. Se possível, use a JVM a partir do tempo de execução do WebSphere em qualquer plataforma que o WebSphere Application Server suporta.

Em geral, utilize a versão mais recente disponível do Java Platform, Standard Edition para obter melhor desempenho.

Tamanho de Heap

A recomendação é heaps de 1 a 2 GB com uma JVM para cada quatro núcleos. O número do tamanho de heap ideal depende dos seguintes fatores:
  • Quantidade de objetos ativos no heap.
  • Complexidade dos objetos ativos no heap.
  • Quantidade de núcleos disponíveis para a JVM.

Por exemplo, um aplicativo que armazena matrizes de 10 KB pode executar um heap muito maior do que um aplicativo que usa gráficos complexos de POJOs.

Contagem de Encadeamentos

A contagem de encadeamentos depende de poucos fatores. Há um limite de quantos encadeamentos um único shard pode gerenciar. Um shard é uma instância de uma partição e pode ser primário ou de réplica. Com mais shards para cada JVM, você possui mais encadeamentos com cada shard adicional fornecendo mais caminhos simultâneos para os dados. Embora cada shard é simultâneo o máximo possível, essa simultaneidade ainda é limitada.

Requisitos do Object Request Broker (ORB)

O IBM SDK inclui uma implementação IBM ORB que foi testada com o WebSphere Application Server e o WebSphere eXtreme Scale. Para facilitar o processo de suporte, use um JVM fornecido pela IBM. Outras implementações de JVM utilizam um ORB diferente. O IBM ORB é fornecido apenas com Java virtual machines fornecidas pela IBM. O WebSphere eXtreme Scale requer um ORB em funcionamento para operar. O WebSphere eXtreme Scale pode ser usado com ORBs a partir de outros fornecedores. No entanto, se você tiver um problema com um ORB do fornecedor, você deve entrar em contato com o fornecedor do ORB para obter suporte. A implementação do IBM ORB é compatível com Java virtual machines de terceiros e pode ser substituído, se necessário.

Ajuste de orb.properties

No laboratório, o seguinte arquivo foi usado nas grades de dados de até 1500 JVMs. O arquivo orb.properties está na pasta lib do ambiente de tempo de execução.
# IBM JDK properties for ORB
org.omg.CORBA.ORBClass=com.ibm.CORBA.iiop.ORB
org.omg.CORBA.ORBSingletonClass=com.ibm.rmi.corba.ORBSingleton

# WS Interceptors
org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ws.objectgrid.corba.ObjectGridInitializer

# WS ORB & Plugins properties
com.ibm.CORBA.ForceTunnel=never
com.ibm.CORBA.RequestTimeout=10
com.ibm.CORBA.ConnectTimeout=10

# Needed when lots of JVMs connect to the catalog at the same time
com.ibm.CORBA.ServerSocketQueueDepth=2048

# Clients and the catalog server can have sockets open to all JVMs
com.ibm.CORBA.MaxOpenConnections=1016

# Thread Pool for handling incoming requests, 200 threads here
com.ibm.CORBA.ThreadPool.IsGrowable=false
com.ibm.CORBA.ThreadPool.MaximumSize=200
com.ibm.CORBA.ThreadPool.MinimumSize=200
com.ibm.CORBA.ThreadPool.InactivityTimeout=180000

# No splitting up large requests/responses in to smaller chunks
com.ibm.CORBA.FragmentSize=0