Evictors

Dados removidos dos evictors a partir da grade de dados. É possível configurar um evictor baseado em tempo ou, como os evictors estão associados aos BackingMaps, usar a interface BackingMap para especificar o desocupador plugável.

Tipos de Evictor

Um evictor TTL padrão é criado com cada mapa de apoio dinâmico. O evictor remove entradas com base em um conceito de tempo de vida.
Nenhum

Especifica que as entradas nunca expiram e, portanto, nunca são removidas do mapa.

Hora de Criação

Especifica que as entradas são despejadas dependendo de quando foram criadas.

Se você estiver usando o Horário de CriaçãoCREATION_TIME ttlType, o evictor despejará uma entrada quando seu horário de criação for igual a seu valor de TTL atributo TimeToLive, que é configurado em milissegundos na configuração do aplicativo. Se você configurar o valor de TTL atributo TimeToLive como 10 segundos, a entrada será despejada automaticamente dez segundos após ser inserida.

É importante tomar cuidado ao configurar este valor para o tipo de evictor Horário de CriaçãoCREATION_TIME ttlType. Este evictor é melhor utilizado quando existem quantidades de inclusões no cache razoavelmente altas que são utilizadas apenas durante uma quantidade de tempo configurada. Com esta estratégia, tudo o que é criado é removido após a quantidade de tempo configurada.

O tipo de evictor Horário de Criação CREATION_TIME ttlType é útil em cenários como a atualização de cotações de ações a cada 20 minutos ou menos. Suponha que um aplicativo da Web obtenha cotas de estoque e que obter as cotas mais recentes não seja crítico. Neste caso, as cotações de ações são armazenadas em cache em uma gradeum ObjectGrid por 20 minutos. Após 20 minutos, as entradas do mapa de grade um ObjectGrid expiram e são despejadas. A cada vinte minutos ou quase, a grade um mapa do ObjectGrid usa o plug-in do Carregador para atualiza os dados com os dados do banco de dados. O banco de dados é atualizado a cada 20 minutos com os preços de ações mais recentes.

Horário do último acesso

Especifica que as entradas são despejadas dependendo de quando foram acessadas pela última vez, se foram lidas ou atualizadas.

Horário da última atualização

Especifica que as entradas são despejadas dependendo de quando foram atualizadas pela última vez.

Se você estiver usando o tipo de evictor Horário do Último Acesso LAST_ACCESS_TIME ou Horário da Última Atualizaçãoatributo ttlType LAST_UPDATE_TIME, configure o valor do TTL TimeToLive para um número menor do que se você estivesse usando o evictor Horário de CriaçãoCREATION_TIME ttlTypeporque as entradas atributo TimeToLive são reconfiguradas toda vez que ele acessado. Em outras palavras, se o atributo TimeToLive for igual a 15 e uma entrada existiu por 14 segundos, mas for acessada, ela não expirará novamente durante outros 15 segundos. Se você configurar o valor de TTL TimeToLive como um número relativamente alto, muitas entradas talvez nunca sejam despejadas. No entanto, se você configurar o valor como algo semelhante a 15 segundos, as entradas poderão ser removidas quando não forem acessadas com freqüência.

O tipo de evictor Horário do Último AcessoLAST_ACCESS_TIME ou Horário da Última Atualização LAST_UPDATE_TIME ttlType é útil é útil em cenários, tais como, a retenção de dados da sessão de um cliente, usando um mapa de um ObjectGrid grade. Os dados de sessão devem ser destruídos se o cliente não utilizá-los por algum período de tempo. Por exemplo, é excedido o tempo limite dos dados de sessão após 30 minutos sem atividade do cliente. Neste caso, usar um tipo de evictor Horário do Último Acesso LAST_ACCESS_TIME ou LAST_UPDATE_TIME Horário da Última Atualização com o valor de TTLatributo TimeToLive configurado como 30 minutos é apropriado para esse aplicativo.

Também é possível gravar seus próprios evictors: Para obter informações adicionais, consulte Gravando um Evictor Customizado.

Evictor Conectável

O evictor TTL padrão utiliza uma política de evicção baseada no tempo e o número de entradas no BackingMap não tem efeito sobre o tempo de expiração de uma entrada. É possível utilizar um evictor conectável opcional para despejar entradas com base no número de entradas existentes em vez de no tempo.

Os seguintes evictores conectáveis opcionais fornecem alguns algoritmos comumente utilizados para decidir quais entradas liberar quando um BackingMap crescer além de algum limite de tamanho.
  • O evictor LRUEvictor utiliza um algoritmo LRU (Least Recently Used) para decidir quais entradas serão despejadas quando o BackingMap exceder um número máximo de entradas.
  • O evictor LFUEvictor utiliza um algoritmo LFU (Least Frequently Used) para decidir quais entradas serão despejadas quando o BackingMap exceder um número máximo de entradas.

O BackingMap informa um evictor conforme as entradas são criadas, modificadas ou removidas de uma transação. O BackingMap acompanha estas entradas e escolhe quando liberar uma ou mais entradas da instância do BackingMap.

Uma instância do BackingMap não possui informações de configuração para um tamanho máximo. Em vez disso, as propriedades do evictor são configuradas para controlar o comportamento do evictor. O LRUEvictor e o LFUEvictor possuem uma propriedade de tamanho máximo utilizada para fazer o evictor começar a liberar entradas quando o tamanho máximo for excedido. Assim como o evictor TTL, os evictores LRU e LFU podem não liberar imediatamente uma entrada quando o número máximo de entradas for atingido para minimizar o impacto no desempenho.

Se o algoritmo LRU ou LFU não for adequado para um determinado aplicativo, será possível redigir seus próprios evictors para criar a sua estratégia de despejo.

Despejo Baseado em Memória

Importante: O despejo baseado em memória é suportado somente no Java Platform, Enterprise Edition Versão 5 ou posterior.

Todos os evictores integrados suportam despejo baseado em memória, que pode ser ativado na interface BackingMap através da configuração do atributo evictionTriggers de BackingMap como MEMORY_USAGE_THRESHOLD. Para obter mais informações sobre como configurar o atributo evictionTriggers no BackingMap, consulte o Interface BackingMap e o Arquivo XML descritor do ObjectGrid.

O despejo baseado em memória é baseado no limite de uso do heap. Quando o despejo baseado em memória é ativado no BackingMap e o BackingMap possui algum evictor integrado, o limite de uso é configurado com uma porcentagem padrão de memória total se o limite ainda não tiver sido configurado anteriormente.

Ao usar o despejo baseado em memória, você deveria configurar o limite de coleta de lixo para o mesmo valor que a utilização de heap de destino. Por exemplo, se o limite de despejo baseado em memória for configurado em 50 por cento e o limite de coleta de lixo estiver configurado no nível padrão de 70 por cento, então a utilização de heap pode chegar no máximo a 70 por cento. Esta aumento da utilização de heap ocorre proque o despejo baseado em memória é acionado somente depois de um ciclo de coleta de lixo.

Para alterar a porcentagem de limite de uso, configure a propriedade memoryThresholdPercentage no contêiner e o arquivo de propriedades do servidor para o processo do servidor do eXtreme Scale. Para configurar o limite de uso de destino em um processo de cliente, é possível usar o MemoryPoolMXBean.

O algoritmo de despejo baseado em memória usado pelo WebSphere eXtreme Scale é sensível ao comportamento do algoritmo de coleta de lixo em uso. O melhor algoritmo para despejo baseado em memória é o padrão da IBM® através do coletor. A geração de algoritmos de coleta de lixo podem provocar comportamento indesejado e, dessa forma, você não deve usar estes algoritmos com o despejo baseado em memória.

Para alterar a porcentagem de limite de uso, configure a propriedade memoryThresholdPercentage no contêiner e os arquivos de propriedades do servidor para os processos do servidor do eXtreme Scale.

Durante o tempo de execução, se o uso da memória exceder o limite de uso destinado, os evictors baseados em memória iniciam o despejo de entradas e tentam manter o uso da memória abaixo do limite de uso destinado. Porém, não há garantia de que a velocidade do despejo seja rápida o suficiente para evitar um possível erro de falta de memória se o tempo de execução do sistema continuar consumindo memória rapidamente.