Limpeza de revisão revision-cleanup

O formato de persistência da TarMK muda com o AEM 6.5. Essas alterações não exigem uma etapa de migração proativa. Os repositórios existentes passam por uma migração contínua, que é transparente para o usuário. O processo de migração é iniciado na primeira vez que o AEM 6.5 (ou ferramentas relacionadas) acessa o repositório.

Depois que a migração para o formato de persistência AEM 6.5 é iniciada, o repositório não pode ser revertido para o formato de persistência AEM 6.3 anterior.

No AEM 6.3, foram necessárias alterações no formato de armazenamento, especialmente para melhorar o desempenho e a eficácia da Limpeza de revisão on-line. Essas alterações não são compatíveis com versões anteriores e os repositórios criados com o segmento Oak antigo (AEM 6.2 e anterior) devem ser migrados.

Benefícios adicionais da alteração do formato de armazenamento:

• Melhor escalabilidade (tamanho de segmento otimizado).
• Mais rápido Coleta de lixo do armazenamento de dados.
• Trabalho de base para aprimoramentos futuros.

A Limpeza de revisão offline está recuperando tudo, exceto a geração mais recente, em comparação às duas gerações mais recentes da Limpeza de revisão online. Se houver um repositório novo, a Limpeza de revisão online não recuperará espaço quando executada pela primeira vez após a Limpeza de revisão offline porque não há geração antiga o suficiente para ser recuperada.

Além disso, leia a seção "Execução de limpeza de revisão online após a limpeza de revisão offline" do este capítulo.

Os fatores são:

• Tamanho do repositório
• Carregar no sistema (solicitações por minuto, especificamente operações de gravação)
• Padrão de atividade (leituras versus gravações)
• Especificações de hardware (desempenho de CPU, memória, IOPS)

O espaço em disco é continuamente monitorado durante a Limpeza de revisão on-line. Se o espaço em disco disponível ficar abaixo de um valor crítico, o processo será cancelado. O valor crítico é 25% do espaço em disco atual do repositório e não é configurável.

A Adobe recomenda que você dimensione o disco pelo menos duas ou três vezes maior que o tamanho estimado do repositório.

O espaço livre em heap é continuamente monitorado durante o processo de limpeza. Se o espaço livre do heap cair abaixo de um valor crítico, o processo será cancelado. O valor crítico é configurado por meio de org.apache.jackrabbit.oak.segment.SegmentNodeStoreService#MEMORY_THRESHOLD. O valor padrão é 15%.

O Recommendations para dimensionamento mínimo de heap de compactação não é separado das recomendações de dimensionamento de memória do AEM. Geralmente: Se uma instância de AEM for dimensionada o suficiente para lidar com os casos de uso e a carga esperada, o processo de limpeza obterá memória suficiente.

• Certifique-se de que ele seja executado diariamente.
• Certifique-se de que ele seja executado durante as atividades mínimas do repositório, configurando as janelas de manutenção no Painel de operações adequadamente.
• Aumente os recursos do sistema (CPU, memória, E/S).

A Limpeza de revisão depende de uma fase de estimativa para decidir se há lixo suficiente para ser limpo. O avaliador compara o tamanho atual com o tamanho do repositório após a última compactação. Se o tamanho exceder o delta configurado, a limpeza será executada. O delta de tamanho é definido em 1 GB. Isso significa que, se o tamanho do repositório não aumentar em 1 GB desde a última execução de limpeza, a nova iteração de limpeza de revisão será ignorada.

Abaixo estão as entradas de log relevantes para a fase de estimativa:

• O GC de revisão é executado: O delta de tamanho é N% ou N/N (N/N bytes), portanto, executando a compactação
• O Revision GC faz não executar: O delta de tamanho é N% ou N/N (N/N bytes), então a compactação é ignorada por enquanto

Se houver simultaneidade de gravação no sistema, a limpeza de revisão on-line poderá exigir acesso de gravação exclusivo para poder confirmar as alterações no final de um ciclo de compactação. O sistema entra em modo forceCompact, tal como explicado mais pormenorizadamente na seção Documentação do Oak. Durante a compactação forçada, um bloqueio de gravação exclusivo é adquirido para finalmente confirmar as alterações sem nenhuma interferência de gravações simultâneas. Para limitar o impacto nos tempos de resposta, um valor de tempo limite pode ser definido. Esse valor é definido como um minuto por padrão, o que significa que se a opção de forçar a compactação não for concluída em um minuto, o processo de compactação será anulado em favor de confirmações simultâneas.

A duração da força compacta depende dos seguintes fatores:

• hardware: especificamente IOPS. A duração diminui com mais IOPS.
• tamanho do armazenamento de segmentos: a duração aumenta de acordo com o tamanho do armazenamento de segmentos.

Em uma configuração de standby inativo, somente a instância principal deve ser configurada para executar a Limpeza de revisão on-line. Na instância de standby, a Limpeza de revisão on-line não precisa ser programada especificamente.

A operação correspondente em uma instância em espera é a Limpeza automática, que corresponde à fase de limpeza da Limpeza de revisão on-line. A Limpeza Automática é executada na instância stand-by após a execução da Limpeza de Revisão On-line na instância principal.

As fases de estimativa e compactação não serão executadas em uma instância em espera.

A Limpeza de revisão offline pode remover imediatamente revisões antigas, enquanto a Limpeza de revisão online deve considerar as revisões antigas que ainda estão sendo referenciadas pela pilha do aplicativo. A primeira pode, assim, remover o lixo de forma mais agressiva do que a segunda, onde o efeito é amortizado ao longo de alguns ciclos de coleta de lixo.

Além disso, leia a seção "Execução de limpeza de revisão online após a limpeza de revisão offline" do este capítulo.

• Em ambientes Windows, o acesso regular a arquivos é sempre aplicado, de modo que o acesso mapeado à memória não é usado. Como conselho geral, toda a RAM disponível deve ser alocada para o heap e o tamanho do segmentCache deve ser aumentado. Você aumenta o segmentCache adicionando a opção segmentCache.size à org.apache.jackrabbit.oak.segment.SegmentNodeStoreService.config (por exemplo, segmentCache.size=20480). Lembre-se de deixar de fora alguma RAM para o sistema operacional e outros processos.
• Em ambientes não Windows, aumente o tamanho da memória física para melhorar o mapeamento da memória do repositório.

• O espaço em disco deve ser monitorado quando a Limpeza de Revisão Online estiver habilitada. A limpeza não é executada ou é encerrada preventivamente quando não há espaço em disco suficiente.
• Verifique os logs para a hora de conclusão da Limpeza de revisão online. Não deve levar mais de 2 horas.
• Número de pontos de verificação. Se houver mais de três pontos de verificação ao executar a compactação, será recomendável limpar os pontos de verificação.

Você pode verificar se a Limpeza de revisão online foi concluída com êxito verificando os logs.

Por exemplo, "TarMK GC #{}: compaction completed in {} ({} ms), after {} cycles" significa que a etapa de compactação foi concluída com êxito, a menos que precedida pela mensagem "TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles", o que significa que havia muita carga simultânea.

Da mesma forma, há uma mensagem "TarMK GC #{}: cleanup completed in {} ({} ms" para a conclusão bem-sucedida da etapa de limpeza.

O status, o progresso e as estatísticas são expostos por meio de JMX (SegmentRevisionGarbageCollection MBean). Para obter mais detalhes sobre o SegmentRevisionGarbageCollection MBean, leia o parágrafo seguinte.

O progresso pode ser monitorado por meio das EstimatedRevisionGCCompletion atributo de SegmentRevisionGarbageCollection MBean.

Você pode obter uma referência do MBean usando o ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection".

As estatísticas só estão disponíveis desde a última inicialização do sistema. Ferramentas de monitoramento externas podem ser usadas para manter os dados além do tempo de atividade do AEM. Consulte a documentação do AEM para anexar verificações de integridade ao Nagios como exemplo para uma ferramenta de monitoramento externa.

• Limpeza de Revisão Online iniciada/interrompida
  • A Limpeza de revisão online é composta por três fases: estimativa, compactação e limpeza. A estimativa pode forçar a compactação e a limpeza a serem ignoradas se o repositório não contiver lixo suficiente. Na versão mais recente do AEM, a mensagem "TarMK GC #{}: estimation started" marca o início da estimativa, "TarMK GC #{}: compaction started, strategy={}" marca o início da compactação e "TarMK GC #{}: cleanup started. Current repository size is {} ({} bytes" marca o início da limpeza.
• Espaço em disco obtido pela limpeza da revisão
  • O espaço é recuperado somente quando a fase de limpeza é concluída. A conclusão da fase de limpeza é marcada pela mensagem de registro "TarMK GC #{}: cleanup completed in {} ({} ms". O tamanho da limpeza da postagem é {} ({} bytes) e espaço recuperado {} ({} bytes). O peso/profundidade do mapa de compactação é {}/{} ({} bytes/{}).".
• Ocorreu um problema durante a limpeza da revisão
  • Há muitas condições de falha, todas elas são marcadas por mensagens de log de AVISO ou ERRO iniciadas com "TarMK GC".

Além disso, consulte a Solução de problemas com base nas mensagens de erro abaixo.

Uma verificação de integridade do repositório não é necessária após a Limpeza de revisão online.

No entanto, você pode executar as seguintes ações para verificar o status do repositório após a limpeza:

• Um repositório verificação de percurso
• Use a ferramenta oak-run após a conclusão do processo de limpeza para verificar se há inconsistências. Para obter mais informações sobre como fazer isso, verifique a Documentação do Apache. Não é necessário desligar o AEM para executar a ferramenta.

A Verificação de integridade da limpeza da revisão faz parte da Painel de operações.

O status é VERDE se a última execução da tarefa de manutenção Limpeza de revisão online foi concluída com êxito.

É necessário AMARELO se a tarefa de manutenção Limpeza de revisão online foi cancelada uma vez.

É necessário VERM se a tarefa de manutenção Limpeza de revisão online foi cancelada três vezes seguidas. Nesse caso, é necessária a interação manual ou a Limpeza de revisão on-line provavelmente falhará novamente. Para obter mais informações, leia a Solução de problemas abaixo.

Além disso, o status da Verificação de integridade é redefinido após a reinicialização do sistema. Assim, uma instância recém-reiniciada mostra um status verde na Verificação de integridade da limpeza de revisão. Ferramentas de monitoramento externas podem ser usadas para manter os dados além do tempo de atividade do AEM. Consulte a documentação do AEM para anexar verificações de integridade ao Nagios como exemplo para uma ferramenta de monitoramento externa.

O status, o progresso e as estatísticas são expostos por meio do JMX usando o SegmentRevisionGarbageCollection MBean. Consulte também o seguinte Documentação do Oak.

Você pode obter uma referência do MBean usando o ObjectName org.apache.jackrabbit.oak:name="Segment node store revision garbage collection",type="SegmentRevisionGarbageCollection".

As estatísticas estão disponíveis somente desde a última inicialização do sistema. Ferramentas de monitoramento externas podem ser usadas para manter os dados além do tempo de atividade do AEM. Além disso, consulte a documentação do AEM para anexar verificações de integridade ao Nagios como exemplo para uma ferramenta de monitoramento externa.

Os arquivos de log também podem ser usados para verificar o status, o andamento e as estatísticas da Limpeza automática.

• O espaço em disco deve ser monitorado quando a Limpeza Automática for executada.
• Tempo de conclusão (por meio dos logs) para garantir que 2 horas não sejam excedidas.
• Tamanho do armazenamento de segmentos após a execução da Limpeza automática. O tamanho do armazenamento de segmentos na instância em standby deve ser aproximadamente o mesmo que o da instância primária.

Você pode executar várias etapas para localizar e corrigir o problema:

• Primeiro, verifique as entradas do log

• Dependendo das informações nos logs, tome as medidas apropriadas:

  • Se os registros mostrarem cinco ciclos compactos perdidos e um tempo limite no forceCompact ciclo, agendar a janela de manutenção para um tempo de silêncio quando a quantidade de gravações no repositório for baixa. Você pode verificar as gravações do repositório na ferramenta de monitoramento de métricas do repositório em https://serveraddress:serverport/libs/granite/operations/content/monitoring/page.html
  • Se a limpeza for interrompida ao final da janela de manutenção, verifique se a configuração da janela de manutenção na interface do usuário Tarefas de manutenção é grande o suficiente
  • Se a memória de heap disponível não for suficiente, verifique se a instância tem memória suficiente.
  • Se houver uma reação tardia, o armazenamento de segmentos poderá crescer demais para que a Limpeza de revisão online seja concluída mesmo em uma janela de manutenção mais longa. Por exemplo, se não houve uma Limpeza de revisão online bem-sucedida concluída na última semana, é recomendável planejar uma manutenção offline e executar a Limpeza de revisão offline para trazer o armazenamento de segmentos de volta a um tamanho gerenciável.

A SegmentNotFoundException é registrado pelo TarMK quando ele tenta acessar uma unidade de armazenamento (um segmento) que não consegue encontrar. Há três cenários que podem causar esse problema:

1. Um aplicativo que contorna os mecanismos de acesso recomendados (como Sling e a API JCR) e usa uma API/SPI de nível inferior para acessar o repositório e, em seguida, excede o tempo de retenção de um segmento. Ou seja, ela mantém uma referência a uma entidade por mais tempo do que o tempo de retenção permitido pela Limpeza de revisão online (24 horas por padrão). Esse caso é transitório e não resulta na corrupção dos dados. Para recuperar, a ferramenta oak-run deve ser usada para confirmar a natureza transitória da exceção (a verificação oak-run não deve relatar erros). Para fazer isso, a instância deve ser colocada offline e reiniciada posteriormente.
2. Um evento externo causou a corrupção dos dados no disco. Isso pode ser uma falha de disco, falta de espaço em disco ou uma modificação acidental dos arquivos de dados necessários. Nesse caso, a instância deve ser colocada offline e reparada usando a verificação oak-run. Para obter mais detalhes sobre como executar a verificação oak-run, leia o seguinte Documentação do Apache.
3. Resolver todas as outras ocorrências por meio do Atendimento ao cliente Adobe.

• Revisão do Oak: O Oak organiza todo o conteúdo em uma grande hierarquia de árvore que consiste em nós e propriedades. Cada instantâneo ou revisão desta árvore de conteúdo é imutável, e as alterações na árvore são expressas como uma sequência de novas revisões. Normalmente, cada modificação de conteúdo aciona uma nova revisão. Consulte também Seguir link.
• Versão da página: O controle de versão cria um "instantâneo" de uma página em um momento específico. Normalmente, uma nova versão é criada quando uma página é ativada. Para obter mais informações, consulte Trabalhar com versões de páginas.