Limpeza de revisão revision-cleanup

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

Depois que a migração para o formato de persistência AEM 6.4 for iniciada, o repositório não poderá 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 Online. Essas alterações não são compatíveis com versões anteriores e os repositórios criados com o segmento antigo do Oak (AEM 6.2 e anterior) devem ser migrados.

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

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

A Limpeza de Revisão Offline recupera tudo, menos a última geração, em comparação com as últimas duas gerações para a Limpeza de Revisão Online. No caso de um repositório novo, a Limpeza de Revisão Online não recuperará espaço quando for executada pela primeira vez após a Limpeza de Revisão Offline, pois não há geração antiga o suficiente para ser recuperada.

Além disso, leia a seção "Executando Limpeza de Revisão Online após Limpeza de Revisão Offline" de 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 da CPU, memória, IOPS)

O espaço em disco é continuamente monitorado durante a Limpeza de Revisão Online. Se o espaço em disco disponível cair abaixo de um valor crítico, o processo será cancelado. O valor crítico é 25% do espaço ocupado pelo disco atual do repositório e não é configurável.

Recomenda-se dimensionar o disco pelo menos duas ou três vezes maior que o tamanho do repositório inicialmente estimado.

O espaço livre de heap é continuamente monitorado durante o processo de limpeza. Se o espaço livre de 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 AEM. Regra geral: Se uma instância de AEM for dimensionada adequadamente para lidar com os casos de uso e a carga esperada nela, 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 de acordo.
• 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 ser compactado pela última vez. Se o tamanho exceder o delta configurado, a limpeza será executada. O tamanho delta é definido em 1 GB. Isso significa que, efetivamente, se o tamanho do repositório não cresceu 1 GB desde a última execução da limpeza, a nova iteração de limpeza da revisão será ignorada.

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

• O GC de revisão será executado: O tamanho delta é N% ou N/N (bytes N/N), portanto, a execução da compactação
• Revisão do GC not executar: O delta de tamanho é N% ou N/N (bytes N/N), portanto, ignorando a compactação por enquanto

Se houver simultaneidade de gravação no sistema, a limpeza de revisão online pode exigir acesso exclusivo de gravação para poder confirmar as alterações no final de um ciclo de compactação. O sistema entrará em modo forceCompact, conforme explicado com mais detalhes na documentação do oak. Durante a compactação forçada, um bloqueio de gravação exclusivo é adquirido para finalmente confirmar as alterações sem interferência de gravações simultâneas. Para limitar o impacto nos tempos de resposta, é possível definir um valor de tempo limite. Esse valor é definido como 1 minuto por padrão, o que significa que se o compacto de força não for concluído em 1 minuto, o processo de compactação será anulado em favor de commits simultâneos.

A duração do pacto de força depende dos seguintes fatores:

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

Em uma configuração de standby frio, somente a instância principal precisa ser configurada para executar a Limpeza de Revisão Online. Na instância de standby, a Limpeza de Revisão Online não precisa ser programada especificamente.

A operação correspondente em uma instância de standby é a Limpeza Automática - isso corresponde à fase de limpeza da Limpeza de Revisão Online. A Limpeza Automática é executada na instância de standby após a execução da Limpeza de Revisão Online na instância principal.

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

A Limpeza de Revisão Offline pode remover imediatamente as revisões antigas, enquanto a Limpeza de Revisão Online precisa considerar as revisões antigas que ainda estão sendo referenciadas pela pilha de aplicativos. A primeira pode, assim, retirar o lixo mais agressivamente do que a segunda, onde o efeito é amortizado ao longo de alguns ciclos de coleta de lixo.

Além disso, leia a seção "Executando Limpeza de Revisão Online após Limpeza de Revisão Offline" de este capítulo.

• Em ambientes Windows, o acesso regular a arquivos é sempre aplicado para que o acesso mapeado à memória não seja usado. Como conselho geral, toda a RAM disponível deve ser alocada no heap e o tamanho segmentCache deve ser aumentado. Você aumenta o segmentCache adicionando a opção segmentCache.size ao 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 que não sã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 ativada. A limpeza não será executada ou terminará preventivamente quando não houver espaço em disco suficiente.
• Verifique os registros quanto ao tempo de conclusão da Limpeza de Revisão Online. Não deve demorar mais de 2 horas.
• Número de pontos de verificação. Se houver mais de 3 pontos de verificação quando a compactação for executada, é 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 seja precedida pela mensagem "TarMK GC #{}: compaction gave up compacting concurrent commits after {} cycles", o que significa que havia muita carga simultânea.

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

Status, progresso e estatísticas são expostos via JMX (SegmentRevisionGarbageCollection MBean). Para obter mais detalhes sobre o SegmentRevisionGarbageCollection MBean, leia o seguinte parágrafo.

O progresso pode ser acompanhado pelo EstimatedRevisionGCCompletion do 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”.

Observe que as estatísticas só estão disponíveis desde o último início do sistema. Ferramentas de monitoramento externo podem ser aproveitadas para manter os dados além AEM tempo de atividade. Consulte a documentação AEM para anexar os controlos de saúde ao Nagios como exemplo para uma ferramenta de monitorização externa.

• A Limpeza de Revisão Online foi iniciada / parada
  • A Limpeza de Revisão Online é composta de três fases: estimativa, compactação e limpeza. A estimativa pode forçar a compactação e a limpeza a ignorar 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 log "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 AVISO ou ERRO começando com "TarMK GC".

Além disso, consulte o Solução de problemas com base em 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 transversal
• 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, marque a opção Documentação do Apache. Não é necessário desligar o AEM para executar a ferramenta.

O Exame de integridade da limpeza da revisão faz parte do Painel de operações.

O status será VERDE se a última execução da tarefa de manutenção Limpeza de Revisão Online tiver sido concluída com êxito.

Será AMARELO se a tarefa de manutenção Limpeza de Revisão Online foi cancelada uma vez.

Será VERMELHO se a tarefa de manutenção Limpeza de Revisão Online foi cancelada três vezes seguidas. Nesse caso, é necessária interação manual ou a Limpeza de Revisão Online provavelmente falhará novamente. Para obter mais informações, leia a Solução de problemas abaixo.

Observe também que o status da verificação de integridade será redefinido após a reinicialização do sistema. Portanto, uma instância recém-reiniciada mostrará um status verde na Verificação de integridade da limpeza de revisão. Ferramentas de monitoramento externo podem ser aproveitadas para manter os dados além AEM tempo de atividade. Consulte a documentação AEM para anexar os controlos de saúde ao Nagios como exemplo para uma ferramenta de monitorização externa.

O status, o progresso e as estatísticas são expostos via JMX usando a variável SegmentRevisionGarbageCollection MBean. Veja 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”.

Observe que as estatísticas estão disponíveis somente desde o último início do sistema. As ferramentas de monitoramento externo podem ser aproveitadas para manter os dados além do tempo de atividade AEM. Consulte também a documentação AEM para anexar os controlos de saúde ao Nagios como exemplo para uma ferramenta de monitorização externa.

Os arquivos de log também podem ser usados para verificar o status, o progresso 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 de standby deve ser aproximadamente o mesmo da instância principal.

É possível seguir várias etapas para encontrar e corrigir o problema:

• Primeiro, verifique as entradas de log

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

  • Se os registros mostrarem cinco ciclos compactos ausentes e um tempo limite no forceCompact ciclo, programe a janela de manutenção para um horário silencioso quando a quantidade de gravações do repositório for baixa. Você pode verificar as gravações do repositório na ferramenta de monitoramento de métricas do repositório localizada em https://serveraddress:serverport/libs/granite/operations/content/monitoring/page.html
  • Se a limpeza parou no 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 heap disponível não for suficiente, verifique se a instância tem memória suficiente.
  • No caso de uma reação tardia, o armazenamento de segmentos pode 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 houver 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 tenta acessar uma unidade de armazenamento (um segmento) que não pode ser encontrada. Há três cenários que podem causar esse problema:

1. Um aplicativo que evita 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, ele 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 em corrupção de 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 nenhum erro). Para fazer isso, a instância precisa ser colocada offline e reiniciada posteriormente.
2. Um evento externo causou a corrupção dos dados no disco. 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 precisa 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. Todas as outras ocorrências devem ser abordadas através da variável Atendimento ao cliente do 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 dessa á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 ponto específico do tempo. Normalmente, uma nova versão é criada quando uma página é ativada. Para obter mais informações, consulte Trabalhar com versões de página.