Limpeza de revisão

Introdução

Cada atualização no repositório cria uma nova revisão de conteúdo. Como resultado, a cada atualização o tamanho do repositório aumenta. Para evitar o crescimento descontrolado do repositório, é necessário limpar revisões antigas para liberar recursos de disco. Esta funcionalidade de manutenção é chamada de Limpeza de revisão. Ele está disponível como uma rotina offline desde AEM 6.0.

Com o AEM 6.3 foi introduzida uma versão on-line dessa funcionalidade chamada Online Revision Cleanup. Em comparação com a Limpeza de revisão offline, onde a instância AEM precisa ser desligada, a Limpeza de revisão online pode ser executada enquanto a instância AEM estiver online. A Limpeza de revisão online está ativada por padrão e é a maneira recomendada de executar uma limpeza de revisão.

Observação: Consulte o Vídeo para obter uma introdução e como usar a Limpeza de revisão online.

O processo de limpeza da revisão consiste em três fases: estimated, compaction e limpeza. A estimativa determina se a próxima fase (compactação) deve ser executada ou não com base na quantidade de lixo que pode ser coletada. Durante a fase de compactação, os segmentos e arquivos tar são regravados, excluindo qualquer conteúdo não utilizado. A fase de limpeza remove subsequentemente os segmentos antigos, incluindo qualquer lixo que eles possam conter. O modo offline geralmente pode recuperar mais espaço porque o modo online precisa levar em conta AEM conjunto de trabalho que retém a coleta de segmentos adicionais.

Para obter mais detalhes sobre a Limpeza de revisão, consulte os seguintes links:

Além disso, você também pode ler a documentação do Oak oficial.

Quando usar a Limpeza de revisão online em vez da Limpeza de revisão offline?

A Limpeza de revisão on-line é a maneira recomendada de realizar a limpeza de revisão. A limpeza de revisão offline deve ser usada somente em uma base excepcional - por exemplo, antes de migrar para o novo formato de armazenamento ou se o Atendimento ao cliente da Adobe solicitar que você faça isso.

Como executar a limpeza de revisão online

A Limpeza de revisão online é configurada por padrão para ser executada automaticamente uma vez por dia nas instâncias de autor e publicação do AEM. Tudo o que você precisa fazer é definir a janela de manutenção durante um período com a menor atividade do usuário. Você pode configurar a tarefa de Limpeza de revisão online da seguinte maneira:

  1. Na janela principal do AEM, vá para Ferramentas - Operações - Painel - Manutenção ou aponte o navegador para: https://serveraddress:serverport/libs/granite/operations/content/maintenance.html

    chlimage_1-90

  2. Passe o mouse sobre Janela de manutenção diária e clique no ícone Configurações.

    chlimage_1-91

  3. Insira os valores desejados (recorrência, hora do start, hora de término) e clique em Salvar.

    chlimage_1-92

Como alternativa, se quiser executar a tarefa de limpeza de revisão manualmente, você pode:

  1. Vá para Ferramentas - Operações - Painel - Manutenção ou navegue diretamente para https://serveraddress:serverport/libs/granite/operations/content/maintenance.html

  2. Clique na Janela de manutenção diária.

  3. Passe o mouse sobre o ícone Limpeza de revisão.

  4. Clique em Executar.

    chlimage_1-93

Executando a Limpeza de Revisão On-line Após a Limpeza de Revisão Off-line

O processo de limpeza da revisão recupera revisões antigas por gerações. Isso significa que cada vez que você executa a limpeza de revisão, uma nova geração é criada e mantida no disco. Entretanto, há uma diferença entre os dois tipos de limpeza de revisão: a limpeza de revisão offline mantém uma geração enquanto a limpeza de revisão online mantém duas gerações. Portanto, quando você executa a limpeza de revisão on-line depois da limpeza de revisão off-line, acontece o seguinte:

  1. Após a primeira limpeza de revisão on-line, o repositório será duplo. Isso acontece porque agora há duas gerações que ficam em disco.
  2. Durante as execuções subsequentes, o repositório crescerá temporariamente enquanto a nova geração for criada e estabilizará de volta ao tamanho que teve após a primeira execução, à medida que o processo de limpeza de revisão online recupera a geração anterior.

Além disso, lembre-se de que, dependendo do tipo e do número de confirmações, cada geração pode variar de tamanho em relação à anterior, de modo que o tamanho final pode variar de uma execução para outra.

Devido a esse fato, é recomendável dimensionar o disco pelo menos duas ou três vezes maior que o tamanho do repositório inicialmente estimado.

Modos de compactação completos e de cauda

AEM 6.5 apresenta dois novos modelos para a fase de ​compactação do processo de Limpeza de revisão online:

  • O modo compactação completa regrava todos os segmentos e arquivos tar em todo o repositório. A fase de limpeza subsequente pode, assim, remover a quantidade máxima de lixo no repositório. Como a compactação completa afeta todo o repositório, ela requer uma quantidade considerável de recursos e tempo para ser concluída. A compactação completa corresponde à fase de compactação no AEM 6.3.
  • O modo de compactação tail regrava apenas os segmentos e arquivos tar mais recentes no repositório. Os segmentos e arquivos tar mais recentes são os que foram adicionados desde a última vez que a compactação completa ou secundária foi executada. A fase de limpeza subsequente só pode, portanto, remover o lixo contido na parte recente do repositório. Como a compactação de cauda afeta apenas uma parte do repositório, ela requer consideravelmente menos recursos e tempo de conclusão do sistema do que a compactação completa.

Estes modos de compactação constituem uma compensação entre eficiência e consumo de recursos: embora a compactação da cauda seja menos eficaz, também tem menos impacto no funcionamento normal do sistema. Em contraste, a compactação completa é mais eficaz, mas tem um impacto maior no funcionamento normal do sistema.

AEM 6.5 também introduz um mecanismo desduplicação-duplicado de conteúdo mais eficiente durante a compactação, o que reduz ainda mais a área de ocupação do repositório no disco.

Os dois gráficos a seguir apresentam resultados de testes laboratoriais internos que ilustram a redução do tempo médio de execução e da pegada média no disco no AEM 6.5 em comparação com o AEM 6.3:

onrc-duration-6_4vs63 segmentstore-6_4vs63

Como configurar a compactação completa e final

A configuração padrão executa compactação de cauda em dias da semana e compactação completa aos domingos. A configuração padrão pode ser alterada usando o novo valor de configuração full.gc.days da RevisionCleanupTask tarefa de manutenção.

Ao configurar o valor full.gc.days, lembre-se de que a compactação completa será executada durante o(s) dia(s) definido(s) na compactação do valor e da cauda durante os dias que não estão definidos no valor. Por exemplo, se você configurar a compactação completa para ser executada no domingo, a compactação de rabo será executada de segunda a sábado. Por exemplo, se você configurar a compactação completa para ser executada todos os dias da semana, a compactação de cauda não será executada.

Além disso, tenha em consideração que:

  • A compactação de cauda é menos eficaz e tem menos impacto nas operações normais do sistema. Pretende - se, assim, que a sua duração seja de dias úteis.
  • A compactação completa é mais eficaz, mas tem também um impacto maior nas operações normais do sistema. Pretende - se, assim, ser utilizado fora dos dias úteis.
  • A compactação da cauda e a compactação completa devem ser executadas durante as horas fora do pico.

Resolução de problemas

Ao usar os novos modos de compactação, lembre-se do seguinte:

  • Você pode monitorar a atividade de entrada/saída (E/S), por exemplo: Operações de E/S, CPU aguardando E/S, confirmar tamanho da fila. Isso ajuda a determinar se o sistema está se tornando vinculado a E/S e requer o redimensionamento.
  • O RevisionCleanupTaskHealthCheck indica o status geral de integridade da Limpeza de revisão online. Funciona da mesma forma que no AEM 6.3 e não distingue entre compactação completa e a cauda.
  • As mensagens de registro contêm informações relevantes sobre os modos de compactação. Por exemplo, quando start de Limpeza de revisão online, as mensagens de registro correspondentes indicarão o modo de compactação. Além disso, em alguns casos, o sistema reverterá para compactação completa quando estiver programado para executar uma compactação de cauda e as mensagens de registro indicarão essa mudança. As amostras de log abaixo indicam o modo de compactação e a mudança da cauda para compactação completa:
TarMK GC: running tail compaction
TarMK GC: no base state available, running full compaction instead

Limitações conhecidas

Em alguns casos, alternar entre os modos de cauda e compactação completa atrasa o processo de limpeza. Mais precisamente, o repositório crescerá após uma compactação completa (o duplo será feito). O espaço extra será recuperado na compactação subsequente da cauda, quando o repositório cair abaixo do tamanho da compactação pré-cheia. As execuções de tarefas de manutenção paralela também devem ser evitadas.

É recomendável dimensionar o disco pelo menos duas ou três vezes maior que o tamanho do repositório inicialmente estimado.

Perguntas frequentes sobre a limpeza de revisão online

AEM 6.5 Considerações sobre atualização

Perguntas Respostas
O que devo saber quando atualizo para o AEM 6.5?

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

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

Migração para Oak Segment Tar

Perguntas Respostas
Por que preciso migrar o repositório?

No AEM 6.3 foram necessárias alterações no formato do 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 antigo segmento Oak (AEM 6.2 e anterior) devem ser migrados.

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

  • Melhor escalabilidade (tamanho de segmento otimizado).
  • Coleta de Lixo do Data Store mais rápida .
  • Trabalho em terra para futuros aprimoramentos.
O formato anterior do Tar ainda é compatível? Somente a nova barra de segmentos do Oak é suportada com a AEM 6.3.
A migração de conteúdo é sempre obrigatória? Sim. A menos que você start uma nova instância, sempre precisará migrar o conteúdo.
É possível atualizar para a versão 6.3 e fazer a migração mais tarde (por exemplo, usando outra janela de manutenção)? Não, como explicado acima, a migração de conteúdo é obrigatória.
O tempo de inatividade pode ser evitado ao migrar? Não. Este é um esforço único que não pode ser feito em uma instância em execução.
O que acontece se eu executar acidentalmente no formato de repositório incorreto? Se você tentar executar o módulo oak-segment em relação a um repositório oak-segment-tar (ou vice-versa), a inicialização falhará com um IllegalStateException com a mensagem "Formato de segmento inválido". Nenhum dado corrompido ocorrerá.
Será necessário reindexar os índices de pesquisa? Não. A migração de oak-segment para oak-segment-tar introduz alterações no formato de container. Os dados contidos não são afetados e não serão modificados.
Como calcular melhor o espaço em disco esperado necessário durante e após a migração? A migração equivale a recriar o armazenamento de segmentos no novo formato. Isso pode ser usado para estimar o espaço em disco adicional necessário durante a migração. Após a migração, o armazenamento de segmentos antigo pode ser excluído para recuperar espaço.
Como melhor estimar a duração da migração? O desempenho da migração pode ser consideravelmente melhorado se limpeza de revisão offline for executada antes da migração. Todos os clientes devem executá-lo como um pré-requisito do processo de atualização. Em geral, a duração da migração deve ser semelhante à duração da tarefa de limpeza de revisão offline, supondo que a tarefa de limpeza de revisão offline tenha sido executada antes da migração.

Execução da Limpeza de Revisão Online

Perguntas Respostas
Com que frequência a Limpeza de revisão online deve ser executada? Uma vez ao dia. Esta é a configuração padrão no Painel Operações.
Como posso configurar o tempo de start da tarefa de manutenção da Limpeza de revisão online? Consulte a seção Como executar a Limpeza de revisão online.
Existe uma frequência máxima que não deve ser excedida para a Limpeza de revisão online? Recomenda-se executar a Limpeza de Revisão Online uma vez por dia, conforme configurado por padrão.
Quais são os principais indicadores que determinam a frequência com que a Limpeza de revisão online deve ser executada? Não há necessidade de determinar a frequência, pois a Limpeza de revisão online está configurada como uma tarefa de manutenção e é executada automaticamente a cada dia.
Por que a Limpeza de revisão online não recupera nenhum espaço quando executada pela primeira vez? A Limpeza de revisão online recupera revisões antigas por gerações. Uma nova geração é gerada sempre que a limpeza de revisões for executada. Só o conteúdo que tem pelo menos duas gerações será recuperado, o que significa que, em primeiro lugar, não há nada a reclamar.
Por que a primeira Limpeza de revisão on-line não recupera nenhum espaço quando executada após a Limpeza de revisão off-line?

A Limpeza de revisão offline está recuperando 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á nenhum espaço quando 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 a limpeza de revisão online após a limpeza de revisão offline" de this chapter.

Geralmente, o Autor e a Publicação teriam janelas diferentes de Limpeza de Revisão Online? Isso depende do horário comercial e dos padrões de tráfego da presença on-line do cliente. As janelas de manutenção devem ser configuradas fora dos principais tempos de produção para permitir a melhor eficácia de limpeza. Para várias instâncias de publicação de AEM (farm TarMK), as janelas de manutenção para a limpeza de revisão online devem ser escalonadas.
Há algum pré-requisito antes de executar a Limpeza de revisão online?

A Limpeza de revisão online está disponível somente com AEM 6.3 e versões posteriores. Além disso, se você estiver usando uma versão mais antiga do AEM, é necessário migrar para a nova Barra de segmentos Oak.

Quais são os fatores que determinam a duração da Limpeza de revisão online? 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)
Os autores ainda podem trabalhar enquanto a Limpeza de revisão online estiver sendo executada? Sim, a Limpeza de revisão online pode lidar com gravações simultâneas. No entanto, a Limpeza de revisão online funciona de forma mais rápida e eficiente sem transações de gravação simultâneas. É recomendável agendar a tarefa de manutenção da Limpeza de revisão online para um tempo relativamente silencioso sem muito tráfego.
Quais são os requisitos mínimos de espaço em disco e memória heap ao executar a Limpeza de revisão online?

O espaço em disco é monitorado continuamente 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 em disco atual do repositório e não é configurável.

É recomendável dimensionar o disco pelo menos duas ou três vezes maior que o tamanho do repositório inicialmente estimado.

O espaço livre no heap é monitorado continuamente 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 AEM. Regra geral: Se uma instância AEM for suficientemente dimensionada para lidar com os casos de uso e com a carga esperada, o processo de limpeza obterá memória suficiente.

Qual é o impacto esperado no desempenho ao executar a Limpeza de revisão online? A Limpeza de revisão online é um processo em segundo plano que lê e grava no repositório simultaneamente nas operações normais do sistema. Em particular, pode ser necessário adquirir o acesso exclusivo ao repositório por um curto período de tempo, impedindo que outros segmentos escrevam no repositório.
Quanto tempo a Limpeza de revisão online deve ser executada? Não deve levar mais de 2 horas para ser executado de acordo com os testes de desempenho mais recentes que realizamos internamente.
O que deve ser feito se a Limpeza de revisão online demorar mais?
  • Certifique-se de que é executado diariamente.
  • Certifique-se de que ele seja executado durante atividades mínimas do repositório, configurando as janelas de manutenção no Operations Painel de acordo.
  • Aumente os recursos do sistema (CPU, Memória, E/S).
O que acontece se a Limpeza de revisão online exceder o Windows de manutenção configurado? Verifique se outras tarefas de manutenção não estão atrasando sua execução. Esse pode ser o caso se mais tarefas de manutenção do que a Limpeza de revisão online forem executadas dentro da mesma janela de manutenção. Observe que as tarefas de manutenção são executadas sequencialmente sem uma ordem configurável.
Por que a coleta de lixo de revisão é ignorada?

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 tamanho delta é definido em 1 GB. Isso significa que, se o tamanho do repositório não aumentar em 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 relevantes do registro para a fase de estimativa:

  • O GC de revisão será executado: O delta de tamanho é N% ou N/N (bytes N/N), portanto, executando a compactação
  • O GC de revisão não será executado: O delta de tamanho é N% ou N/N (bytes N/N), portanto, ignorando a compactação por enquanto
É possível interromper com segurança a compactação automática se o impacto no desempenho for muito alto? Sim. Desde AEM 6.3, pode ser interrompido com segurança através da Janela da Tarefa de Manutenção no Painel Operações ou através do JMX.
Se a instância AEM for desligada durante uma tarefa de limpeza programada, o processo será abortado com segurança ou o desligamento será bloqueado até que a compactação seja concluída? A Limpeza de revisão será interrompida e o repositório será encerrado com segurança.
O que acontece quando o sistema trava durante a Limpeza de revisão online? Nesses casos, não há risco de corrupção de dados. Os restos de lixo serão limpos por uma execução subsequente.
Qual é o impacto de não executar a Limpeza de revisão online? Degradação do desempenho ao longo do tempo.
Quais revisões estão sendo coletadas? Por padrão, a Limpeza de revisão online coleta apenas revisões com pelo menos 24 horas de vida.
O que acontece em caso de interferência excessiva de gravações simultâneas no repositório?

Se houver simultaneidade de gravação no sistema, a limpeza de revisão on-line pode exigir acesso exclusivo de gravação para poder confirmar as alterações ao final de um ciclo de compactação. O sistema entrará no modo forceCompact, conforme explicado em mais detalhes na documentação do carvalho. Durante o pacto de força, um bloqueio de gravação exclusivo é adquirido para finalmente confirmar as mudanças sem que gravações simultâneas interfiram. Para limitar o impacto nos tempos de resposta, um valor de tempo limite pode ser definido. Esse valor é definido como 1 minuto por padrão, o que significa que, se o pacto de força não for concluído dentro de 1 minuto, o processo de compactação será abortado em favor dos compromissos 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.

Como a Limpeza de revisão online é executada em uma instância stand-by?

Em uma configuração em espera fria, somente a instância principal precisa ser configurada para executar a Limpeza de revisão online. Na instância stand-by, a Limpeza de revisão online não precisa ser programada especificamente.

A operação correspondente em uma instância stand-by é a Limpeza automática - isso corresponde à fase de limpeza da Limpeza de revisão online. A Limpeza automática é executada na instância stand-by 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 stand-by.

A Limpeza de revisão offline pode liberar mais espaço em disco do que a Limpeza de revisão online?

A Limpeza de revisão offline pode remover imediatamente revisões antigas enquanto a Limpeza de revisão online precisa levar em conta 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 a limpeza de revisão online após a limpeza de revisão offline" de this chapter.

Alguma consideração sobre operações de arquivos mapeados de memória?
  • Nos ambientes do 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 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 que não sejam do Windows, aumente o tamanho da memória física para melhorar o mapeamento da memória do repositório.

Monitoramento da Limpeza de Revisão Online

O que precisa ser monitorado durante a Limpeza de revisão online?
  • O espaço em disco deve ser monitorado quando a Limpeza de revisão online estiver ativada. A limpeza não será executada ou será encerrada preemptivamente quando não houver espaço em disco suficiente.
  • Verifique nos registros o 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.
Como verificar se a Limpeza de revisão online foi concluída com êxito?

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

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 houve muita carga simultânea.

De forma correspondente, há uma mensagem "TarMK GC #{}: cleanup completed in {} ({} ms" para a conclusão com êxito da etapa de limpeza.

Onde podemos encontrar as estatísticas das últimas execuções de Limpeza de Revisão Online?

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

O progresso pode ser rastreado pelo atributo EstimatedRevisionGCCompletion da variável SegmentRevisionGarbageCollection MBean.

Você pode obter uma referência do MBean usando 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 start do sistema. A ferramenta de monitoramento externo pode ser aproveitada para manter os dados fora AEM tempo de atividade. Consulte a documentação AEM para anexar verificações de integridade a Nagios como exemplo para uma ferramenta de monitoramento externo.

Quais são as entradas relevantes do registro?
  • 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 pular se o repositório não tiver lixo suficiente. Na versão mais recente do AEM, a mensagem "TarMK GC #{}: estimation started" marca o start de estimativa, "TarMK GC #{}: compaction started, strategy={}" marca o start de compactação e "TarMK GC #{}: cleanup started. Current repository size is {} ({} bytes" marca o start de limpeza.
  • Espaço em disco ganho 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 o 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 registro WARN ou ERROR que começam com "TarMK GC".

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

Como verificar quanto espaço foi recuperado após a conclusão da Limpeza de revisão online? Há uma mensagem no registro ao final do ciclo de limpeza: "TarMK GC #3: cleanup completed" que inclui o tamanho do repositório e a quantidade de lixo recuperado.
Como verificar a integridade do repositório após a conclusão da Limpeza de revisão online?

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 de execução de carvalho após a conclusão do processo de limpeza para verificar se há inconsistências. Para obter mais informações sobre como fazer isso, consulte a Documentação do Apache. Não é necessário desligar o AEM para executar a ferramenta.
Como detectar se a Limpeza de revisão online falhou e quais são as etapas para recuperar? As condições de falha são marcadas por mensagens de registro WARN ou ERROR que começam com "TarMK GC". Além disso, consulte a seção Solução de problemas com base em mensagens de erro abaixo.
Que informações são expostas na Verificação de integridade da limpeza de revisão? Como e quando contribuem para os níveis de status de códigos de cores?

A Verificação de integridade da revisão faz parte do Painel Operações.

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

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

Será VERMELHO se a tarefa de manutenção da Limpeza de revisão online for cancelada três vezes seguidas. Nesse caso, a interação manual é necessária; a Limpeza de revisão online provavelmente falhará novamente. Para obter mais informações, leia a seção Resolução de problemas abaixo.

Observe também que o status da verificação de integridade será redefinido após a reinicialização do sistema. Assim, uma instância recém-reiniciada mostrará um status verde na Verificação de integridade da limpeza da revisão. A ferramenta de monitoramento externo pode ser aproveitada para manter os dados fora AEM tempo de atividade. Consulte a documentação AEM para anexar verificações de integridade a Nagios como exemplo para uma ferramenta de monitoramento externo.

Como monitorar a Limpeza automática em uma instância stand-by?

O status, o progresso e as estatísticas são expostos via JMX usando o MBean SegmentRevisionGarbageCollection. Consulte também a 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 start do sistema. A ferramenta de monitoramento externo pode ser aproveitada para manter os dados além do tempo de funcionamento AEM. Além disso, consulte a documentação AEM para anexar verificações de integridade a Nagios como exemplo para uma ferramenta de monitoramento externo.

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

O que precisa ser monitorado durante a Limpeza automática em uma instância stand-by?

  • O espaço em disco deve ser monitorado quando a Limpeza automática for executada.
  • Tempo de conclusão (através dos registros) para garantir que 2 horas não sejam excedidas.
  • Tamanho do armazenamento de segmentos depois que a Limpeza automática é executada. O tamanho do armazenamento de segmentos na instância stand-by deve ser aproximadamente o mesmo da instância principal.

Solução de problemas de limpeza de revisão online

Qual é o pior que pode acontecer se você não executar a Limpeza de revisão online? A instância AEM ficará sem espaço em disco, o que causará paralisações na produção.
O tráfego alto do usuário é problemático para executar a Limpeza de revisão online em uma instância de publicação? O alto tráfego de usuários afeta se a fase de compactação é capaz de terminar ou não com êxito.
De acordo com a Verificação de integridade e as entradas do registro, a Limpeza de revisão online não foi concluída com êxito três vezes seguidas. O que é necessário para que a Limpeza de revisão online seja concluída com êxito? Você pode executar várias etapas para localizar e corrigir o problema:
  • Primeiro, verifique as entradas de registro
  • Dependendo das informações nos registros, tome as medidas apropriadas:
    • Se os registros mostrarem cinco ciclos compactos perdidos e um tempo limite no ciclo forceCompact, agende a janela de manutenção para um tempo silencioso quando a quantidade de gravações no repositório for baixa. Você pode verificar gravações no 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 do Maintenance Tarefa é 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 aumentar demais para que a Limpeza de revisão online seja concluída mesmo dentro de uma janela de manutenção mais longa. Por exemplo, se a Limpeza de revisão online não tiver sido concluída com êxito 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.
O que precisa ser feito quando o alerta de exame de saúde estiver ativado? Ver o ponto anterior.
O que acontece se a Limpeza de revisão online ficar sem tempo durante a janela de manutenção programada? A Limpeza de revisão on-line será cancelada e as sobras serão removidas. Ele será start novamente na próxima vez que a janela de manutenção for programada.
O que está fazendo com que as instâncias SegmentNotFoundException sejam registradas em error.log e como posso recuperar?

Um 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 contorna os mecanismos de acesso recomendados (como Sling e JCR API) 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, mantém uma referência a uma entidade maior que o tempo de retenção permitido pela Limpeza online de revisão (24 horas por padrão). Esse caso é transitório e não resulta em corrupção de dados. Para recuperar, a ferramenta de execução de carvalho deve ser usada para confirmar a natureza transitória da exceção (a verificação de execução de carvalho não deve reportar erros). Para isso, é necessário colocar a instância offline e reiniciá-la depois.
  2. Um evento externo causou a corrupção dos dados no disco. Isso pode ser uma falha de disco, espaço em disco insuficiente ou uma modificação acidental dos arquivos de dados necessários. Nesse caso, a instância precisa ser colocada off-line e reparada usando a verificação de carvalho-run. Para obter mais detalhes sobre como executar a verificação de carvalho, leia a seguinte documentação do Apache.
  3. Todas as outras ocorrências devem ser tratadas pelo Atendimento ao cliente do Adobe.

Solução de problemas com base em mensagens de erro

O error.log será detalhado se houver incidentes durante o processo de limpeza de revisão online. A matriz a seguir tem como objetivo explicar as mensagens mais comuns e fornecer possíveis soluções:

Fase Mensagens de registro Explicação Próximas etapas
Estimativa TarMK GC nº 2: estimativa ignorada porque a compactação está pausada A fase de estimativa é ignorada quando a compactação é desativada no sistema por configuração. Ativar a Limpeza de revisão online.
TarMK GC nº 2: estimativa interrompida: ${RAZÃO}. Ignorando compactação. A fase de estimativa terminou prematuramente. Alguns exemplos de eventos que podem interromper a fase de estimativa: memória ou espaço em disco insuficiente no sistema host. Depende do motivo dado.
Compactação TarMK GC nº 2: compactação pausada Enquanto a fase de compactação for pausada pela configuração, nem a fase de estimativa nem a fase de compactação serão executadas. Habilitar limpeza de revisão online.
TarMK GC nº 2: compactação cancelada: ${RAZÃO}. A fase de compactação terminou prematuramente. Alguns exemplos de eventos que podem interromper a fase de compactação: memória ou espaço em disco insuficiente no sistema host. Além disso, a compactação também pode ser cancelada através do encerramento do sistema ou do cancelamento explícito do sistema através de interfaces administrativas, como a Janela de manutenção no Painel de operações. Depende do motivo dado.
TarMK GC nº 2: a compactação falhou em 32,902 min (1974140 ms), após 5 ciclos Essa mensagem não significa que houve um erro irrecuperável, mas somente que a compactação foi encerrada após uma certa quantidade de tentativas. Além disso, leia o parágrafo a seguir. Leia a seguinte Documentação do Oak e a última pergunta da seção Execução da Limpeza de Revisão Online.
Limpar TarMK GC nº 2: limpeza interrompida A limpeza foi cancelada ao encerrar o repositório. Não se prevê qualquer impacto na coerência. Além disso, é provável que o espaço em disco não seja recuperado na sua totalidade. Ele será recuperado durante o próximo ciclo de limpeza de revisão. Analise por que o repositório foi desligado e tente evitar o desligamento do repositório durante as janelas de manutenção.

Como executar a limpeza de revisão offline

CUIDADO

Diferentes versões da ferramenta Oak-run precisam ser usadas, dependendo da versão Oak usada com a instalação do AEM. Verifique a lista de requisitos de versão abaixo antes de usar a ferramenta:

  • Para as versões Oak 1.0.0 a 1.0.11 ou 1.1.0 a 1.1.6, use a versão Oak-run​*** 1.0.11***

  • Para versões do Oak mais recentes do que as anteriores, use a versão do Oak-run que corresponde ao núcleo do Oak da instalação do AEM.

O Adobe fornece uma ferramenta chamada Oak-run para executar limpeza de revisão. Ele pode ser baixado no seguinte local:

https://repo1.maven.org/maven2/org/apache/jackrabbit/oak-run/

A ferramenta é um jar executável que pode ser executado manualmente para compactar o repositório. O processo é chamado de limpeza de revisão offline porque o repositório precisa ser desligado para executar a ferramenta corretamente. Certifique-se de planejar a limpeza de acordo com a janela de manutenção.

Para obter dicas sobre como aumentar o desempenho do processo de limpeza, consulte Aumentando o desempenho da limpeza de revisão offline.

OBSERVAÇÃO

Você também pode limpar os pontos de verificação antigos antes que a manutenção ocorra (etapas 2 e 3 no procedimento abaixo). Isso é recomendado somente para instâncias que tenham mais de 100 pontos de verificação.

  1. Sempre verifique se você tem um backup recente da instância AEM.

    Desligue AEM.

  2. (Opcional) Use a ferramenta para localizar pontos de verificação antigos:

    java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore
    
  3. (Opcional) Em seguida, exclua os pontos de verificação não referenciados:

    java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore rm-unreferenced
    
  4. Execute a compactação e aguarde até que ela seja concluída:

    java -jar -Dsun.arch.data.model=32 oak-run.jar compact install-folder/crx-quickstart/repository/segmentstore
    

Aumentando o desempenho da limpeza de revisão offline

A ferramenta executada em carvalho apresenta vários recursos que visam aumentar o desempenho do processo de limpeza da revisão e minimizar a janela de manutenção o máximo possível.

A lista inclui vários parâmetros de linha de comando, conforme descrito abaixo:

  • -mmap. Você pode definir isso como verdadeiro ou falso. Se definido como true, o acesso mapeado de memória será usado. Se definido como falso, o acesso ao arquivo será usado. Se não for especificado, o acesso mapeado de memória será usado em sistemas de 64 bits e o acesso a arquivos será usado em sistemas de 32 bits. No Windows, o acesso regular a arquivos é sempre aplicado e essa opção é ignorada. Esse parâmetro substituiu o parâmetro -Dtar.memoryMapped.

  • -Dupdate.limit. Define o limite para a liberação de uma transação temporária em disco. O valor padrão é 10000.

  • -Descompactar intervalo. Número de entradas do mapa de compactação a serem mantidas até a compactação do mapa atual. O padrão é 1000000. Você deve aumentar esse valor para um número ainda maior para obter uma throughput mais rápida, se houver memória heap suficiente disponível. Esse parâmetro foi removido no Oak versão 1.6 e não tem efeito.

  • -Dcompaction-progress-log. O número de nós compactados que serão registrados em log. O valor padrão é 150000, o que significa que os primeiros 150000 nós compactados serão registrados durante a operação. Use-o em conjunto com o próximo parâmetro documentado abaixo.

  • -Dtar.PersistCompactionMap. Defina esse parâmetro como true para usar espaço em disco em vez de memória heap para a persistência do mapa de compactação. Exige a ferramenta de execução de carvalho versões 1.4 e posteriores. Para obter mais detalhes, consulte a pergunta 3 na seção Limpeza de revisão offline Perguntas frequentes. Esse parâmetro foi removido no Oak versão 1.6 e não tem efeito.

  • —força. Forçar compactação e ignorar uma versão de armazenamento de segmentos não correspondente.

CUIDADO

Usar o parâmetro --force atualizará o armazenamento de segmentos para a versão mais recente, que é incompatível com versões anteriores do Oak. Além disso, considere que não é possível qualquer downgrade. Como regra geral, você deve usar esses parâmetros com cautela e somente se tiver conhecimento sobre como usá-los.

Um exemplo dos parâmetros em uso:

java -Dupdate.limit=10000 -Dcompaction-progress-log=150000 -Dlogback.configurationFile=logback.xml -Xmx8g -jar oak-run-*.jar checkpoints <repository>

Métodos adicionais para acionar a limpeza de revisão

Além dos métodos apresentados acima, você também pode acionar o mecanismo de limpeza de revisão usando o console JMX da seguinte maneira:

  1. Abra o console JMX acessando http://localhost:4502/system/console/jmx
  2. Clique em RevisionGarbageCollection MBean.
  3. Na janela seguinte, clique em startRevisionGC() e em Invocar para start do trabalho Revision Garbage Collection.

Perguntas frequentes sobre a limpeza de revisão offline

Quais são os fatores que determinam a duração da Limpeza de revisão offline?

O tamanho do repositório e a quantidade de revisões que precisam ser limpas determinam a duração da limpeza.

Qual é a diferença entre uma revisão e uma versão de página?
  • Revisão de Oak: Oak organiza todo o conteúdo em uma hierarquia de árvore grande 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 no 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.
Como acelerar a tarefa de Limpeza de revisão offline se ela não for concluída em 8 horas? Se a tarefa de revisão não for concluída dentro de 8 horas e o thread despejar revelar que o ponto de conexão principal é InMemoryCompactionMap.findEntry, use o seguinte parâmetro com a ferramenta de execução de carvalho versões 1.4 ou superior: -Dtar.PersistCompactionMap=true. Observe que o parâmetro -Dtar.PersistCompactionMap foi removido no Oak versão 1.6.

Nesta página

Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free