Dimensionamento do Consumo do Cache de Memória

O WebSphere eXtreme Scale pode estimar precisamente o uso de memória do heap Java de um determinado BackingMap em bytes. Use esse recurso para ajudar a dimensionar corretamente as configurações de heap do Java virtual machine e as políticas de desocupação. O comportamento deste recurso varia com a complexidade dos Objects que estão sendo colocados no mapa de retorno e com a forma como o mapa é configurado. Atualmente, este recurso é suportado apenas para grades de dados distribuídas. As instâncias de grade de dados local não suportam o dimensionamento de bytes usados.

Considerações sobre o Consumo de Heap

O eXtreme Scale armazena todos os seus dados dentro do espaço de heap dos processos JVM que compõem a grade de dados. Para um determinado mapa, o espaço de heap que ele consome pode ser dividido nos seguintes componentes:
  • O tamanho de todos os objetos principais atualmente no mapa
  • O tamanho de todos os objetos de valor atualmente no mapa
  • O tamanho de todos os objetos EvictorData que estão em uso pelos plug-ins Evictor no mapa
  • A sobrecarga da estrutura de dados subjacente

O número de bytes usados que são relatados pelas estatísticas de dimensionamento é a soma desses quatro componentes. Esses valores são calculados por entrada nas operações de inserção, atualização e remoção de mapa, significando que o mapa eXtreme Scale tem um valor atual para o número de bytes que um determinado mapa de apoio consume.

Quando grades são particionadas, cada partição contém uma parte do mapa de apoio. Como as estatísticas de dimensionamento são calculadas no nível mais baixo do código do eXtreme Scale, cada partição de um mapa de apoio rastreia seu próprio tamanho. É possível usar as APIs de Estatísticas do eXtreme Scale para rastrear o tamanho acumulativo do mapa e também o tamanho de suas partições individuais.

Em geral, use o dimensionamento de dados como uma medida das tendências de dados ao longo do tempo, e não como uma medida exata do espaço de heap usado pelo mapa. Por exemplo, se o tamanho relatado de um mapa dobra de 5 MB para 10 MB, visualize o consumo de memória do mapa como tendo dobrado. A medida real de 10 MB pode ser exata por vários motivos. Se você levar em conta os motivos e seguir as boas práticas, a exatidão das medidas de tamanho se aproximará daquelas do pós-processamento de um dump de heap Java.

O principal problema com a exatidão é que o Modelo de Memória Java não é restritivo o suficiente para permitir medidas de memória que devem ser exatas. O problema fundamental é que um objeto pode estar ativo no heap devido a várias referências. Por exemplo, se a mesma instância de objeto de 5 KB for inserida em três mapas separados, qualquer um desses três mapas impede que o Object seja posto na lixeira. Nesta situação, qualquer uma das medidas a seguir seria justificável:
  • O tamanho de cada mapa é aumentado em 5 KB.
  • O tamanho do primeiro mapa no qual o Object é posicionado é aumentado em 5 KB.
  • O tamanho dos outros dois mapas não é aumentado. O tamanho de cada mapa é aumentado em uma fração do tamanho do objeto.

Esta ambiguidade se deve porque essas medidas devem ser consideradas como dados de tendência, a não ser que você tenha removido a ambiguidade por meio das opções de design, melhores práticas e do entendimento das opções de implementação que podem fornecer estatísticas mais precisas.

O eXtreme Scale supõe que um determinado mapa retém a única referência de vida longa para os Objects de chave e de valor que ele contém. Se o mesmo objeto de 5 KB for posicionado em três mapas, o tamanho de cada mapa será aumentado em 5 KB. O aumento, geralmente, não é um problema, pois o recurso é suportado apenas para grades de dados distribuídas. Se você inserir o mesmo Object em três mapas diferentes em um cliente remoto, cada mapa recebe sua própria cópia do Object. As configurações COPY MODE transacionais padrão também geralmente garantem que cada mapa tenha sua própria cópia de um determinado Object.

Internalização do Object

A internalização de objeto pode provocar um desafio ao estimar ouso de memória do heap. Ao implementar a internalização de um objeto, o código do aplicativo assegura propositalmente que todas as referências a um determinado valor de objeto realmente apontem para a instância do mesmo objeto no heap e, portanto, o mesmo local na memória. Um exemplo disso pode ser a seguinte classe:
 public class ShippingOrder implements Serializeable,Cloneable{

     public static final STATE_NEW = “new”;
     public static final STATE_PROCESSING = “processing”;
     public static final STATE_SHIPPED = “shipped”;

     private String state;
     private int orderNumber;
	private int customerNumber;

	public Object clone(){
        ShippingOrder toReturn = new ShippingOrder();
        toReturn.state = this.state;
        toReturn.orderNumber = this.orderNumber;
        toReturn.customerNumber = this.customerNumber;
        return toReturn;
     }
 
     private void readResolve(){
         if (this.state.equalsIgnoreCase(“new”)
             this.state = STATE_NEW;
         else if (this.state.equalsIgnoreCase(“processing”)
             this.state = STATE_PROCESSING;
         else if (this.state.equalsIgnoreCase(“shipped”)
             this.state = STATE_SHIPPED:
     }
 }
A internalização do Object causa uma superestimativa ao dimensionar as estatísticas porque o eXtreme Scale supõe que os objetos usam locais de memória diferentes. Se um milhão de objetos ShippingOrder existir, as estatísticas de dimensionamento exibirão o custo de um milhão de Sequências que mantêm as informações de estado. Na realidade, apenas três Sequências existentes são membros estáticos da classe. O custo da memória para os membros estáticos da classe nunca deve ser incluído em nenhum mapa do eXtreme Scale. No entanto, essa situação não pode ser detectada no tempo de execução. Há diversas maneiras pelas quais a internalização de objeto semelhante pode ser implementada, o que explica por que é tão difícil de detectar. Não é prático o eXtreme Scale proteger-se contra todas as implementações possíveis. Entretanto, o eXtreme Scale não protege contra os tipos de internalização de objeto mais normalmente usados. Para otimizar o uso da memória com a internalização de Object, implemente a internalização apenas em objetos personalizados que entram nas duas categorias a seguir para aprimorar a exatidão das estatísticas de consumo de memória:
  • O eXtreme Scale é ajustado automaticamente para enumerações do Java 5 e para o padrão Typesafe Enum, conforme descrito em Visão Geral do Java 2 Platform Standard Edition 5.0: Enumerações.
  • O eXtreme Scale automaticamente leva em consideração a internalização automática de tipos de wrapper primitivos, como Número Inteiro. A internalização automática para tipos de wrapper primitivos foi introduzida no Java 5 por meio da utilização de métodos estáticos do valueOf.

Estatísticas de Consumo de Memória

Use um dos métodos a seguir para acessar as estatísticas de consumo de memória.
API de Estatísticas

Use o método MapStatsModule.getUsedBytes() que fornece estatísticas para um único mapa, incluindo o número de entradas e a taxa de ocorrências.

Para obter detalhes, consulte Módulos Estatísticos.

Beans Gerenciados (MBeans)

Use a estatística MBean gerenciada pelo MapUsedBytes. É possível usar vários tipos diferentes de Java Management Extensions (JMX) MBeans para administrar e monitorar as implementações. Cada MBean faz referência a uma entidade específica, como um mapa, um eXtreme Scale, um servidor, um grupo de replicação ou um membro do grupo de replicação.

Para obter detalhes, consulte Administrando com Beans Gerenciados (MBeans).

Módulos PMI (Performance Monitoring Infrastructure)

É possível monitorar o desempenho de seus aplicativos com os módulos PMI. Especificamente, use o módulo PMI de mapa para contêineres integrados no WebSphere Application Server.

Para obter detalhes, consulte Módulos PMI.

Console do WebSphere eXtreme Scale

Com o console, é possível visualizar as estatísticas de consumo de memória. Consulte o Monitorando com o Console da Web.

Todos esses métodos acessam a mesma medida subjacente do consumo de memória de uma determinada instância BaseMap. O tempo de execução do WebSphere eXtreme Scale tenta, com o melhor esforço, calcular o número de bytes de memória de heap consumidos pelos objetos de chave e de valor que são armazenados no mapa e também a sobrecarga do próprio mapa. É possível ver quanta memória de heap cada mapa consume entre todas as grades de dados distribuídas.

Na maioria dos casos, o valor relatado por WebSphere eXtreme Scale para um determinado mapa é muito próximo do valor relatado pela análise de dump do heap. O WebSphere eXtreme Scale dimensiona exatamente sua própria sobrecarga, mas não pode considerar cada objeto possível que pode ser posicionado em um mapa. Seguir as melhores práticas descritas no Ajustando o Agente de Dimensionamento de Cache para Estimativas Exatas de Consumo de Memória pode melhorar a exatidão do tamanho em medidas de bytes fornecidas pelo WebSphere eXtreme Scale.