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, as revisões antigas precisam ser limpas para liberar recursos de disco. Essa funcionalidade de manutenção é chamada de Revisão de limpeza. Ele está disponível como uma rotina offline desde o AEM 6.0.
Com o AEM 6.3, uma versão online dessa funcionalidade chamada Limpeza de Revisão Online foi introduzida. Comparada à Limpeza de Revisão Offline, onde a instância de AEM deve ser encerrada, a Limpeza de Revisão Online pode ser executada enquanto a instância de AEM estiver online. A Limpeza de Revisão Online é 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 de revisão consiste em três fases: estimativa, compactação 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 os arquivos tar são regravados, sem o 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, pois o modo online precisa considerar AEM conjunto de trabalho que retém segmentos adicionais de serem coletados.
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 oficial do Oak.
A Limpeza de Revisão Online é a maneira recomendada de executar 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 você for solicitado pelo Atendimento ao Cliente do Adobe a fazer isso.
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 Limpeza de Revisão Online da seguinte maneira:
Na janela principal do AEM, vá para Tools - Operations - Dashboard - Maintenance ou aponte o navegador para: https://serveraddress:serverport/libs/granite/operations/content/maintenance.html
Passe o mouse sobre Janela de manutenção diária e clique no ícone Configurações.
Insira os valores desejados (recorrência, hora de início, hora de término) e clique em Save.
Como alternativa, se você quiser executar a tarefa de limpeza de revisão manualmente, poderá:
Vá para Ferramentas - Operações - Painel - Manutenção ou navegue diretamente para https://serveraddress:serverport/libs/granite/operations/content/maintenance.html
Clique na Janela de Manutenção Diária.
Passe o mouse sobre o ícone Revisão de limpeza.
Clique em Executar.
O processo de limpeza de 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. No entanto, 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 online após a limpeza de revisão offline, ocorre o seguinte:
Além disso, lembre-se de que, dependendo do tipo e do número de commits, cada geração pode variar em tamanho em comparaçã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.
O AEM 6.4 apresenta dois novos modelos para a fase de compactação do processo de Limpeza de Revisão Online:
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. Pelo contrário, a compactação completa é mais eficaz, mas tem um impacto maior no funcionamento normal do sistema.
O AEM 6.4 também introduz um mecanismo de desduplicação de conteúdo mais eficiente durante a compactação, o que reduz ainda mais o espaço ocupado em disco pelo repositório.
Os dois gráficos a seguir apresentam resultados de testes laboratoriais internos que ilustram a redução dos tempos de execução médios e da pegada média no disco no AEM 6.4 em comparação com o AEM 6.3:
A configuração padrão executa a compactação de cauda em dias da semana e a compactação completa nos 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) no valor e a compactação de tail será executada 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 cauda 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:
Ao usar os novos modos de compactação, lembre-se do seguinte:
RevisionCleanupTaskHealthCheck
indica o status de integridade geral da Limpeza de Revisão Online. Funciona da mesma forma que no AEM 6.3 e não distingue entre compactação completa e de cauda.TarMK GC: running tail compaction
TarMK GC: no base state available, running full compaction instead
Em alguns casos, alternar entre a cauda e os modos de compactação completos atrasa o processo de limpeza. Mais precisamente, o repositório crescerá após uma compactação completa (dobrará de tamanho). O espaço extra será recuperado na compactação de cauda subsequente, quando o repositório cair abaixo do tamanho de compactação pré-completo. As execuções de tarefas de manutenção paralelas também devem ser evitadas.
Recomenda-se dimensionar o disco pelo menos duas ou três vezes maior que o tamanho do repositório inicialmente estimado.
Perguntas | Respostas |
O que devo estar ciente quando atualizo para o AEM 6.4? | 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. |
Perguntas | Respostas | |
Por que preciso migrar o repositório? | 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:
|
|
O formato Tar anterior ainda é compatível? | Somente o novo Oak Segment Tar é compatível com o AEM 6.3. | |
A migração de conteúdo é sempre obrigatória? | Sim. A menos que você comece com uma nova instância, sempre precisará migrar o conteúdo. | |
Posso atualizar para a versão 6.3 e fazer a migração posteriormente (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. Esse é um esforço único que não pode ser feito em uma instância em execução. | |
O que acontece se eu executar acidentalmente em relação ao formato de repositório incorreto? | Se você tentar executar o módulo oak-segment em um repositório oak-segment-tar (ou vice-versa), a inicialização falhará com um IllegalStateException com a mensagem "Formato de segmento inválido". Não haverá corrupção de dados. | |
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 do contêiner. 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 segmento antigo pode ser excluído para recuperar espaço. | |
Como estimar melhor a duração da migração? | O desempenho da migração pode ser significativamente melhorado se limpeza de revisão offline for executada antes da migração. Todos os clientes são aconselhados a 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. |
Perguntas | Respostas | |
Com que frequência a Limpeza de Revisão Online deve ser executada? | Uma vez ao dia. Essa é a configuração padrão no Painel de operações. | |
Como posso configurar a hora de início da tarefa de manutenção de 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 na qual 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 espaço quando executada pela primeira vez? | A Limpeza de Revisão Online recupera as antigas revisões por gerações. Uma nova geração é gerada sempre que a limpeza da revisão é executada. Apenas o conteúdo que tem pelo menos duas gerações será recuperado, o que significa que, numa primeira execução, não há nada a reclamar. | |
Por que a primeira Limpeza de Revisão Online não recupera espaço quando executada após a Limpeza de Revisão Offline? | 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 this chapter. |
|
O Autor e a Publicação normalmente teriam diferentes janelas de Limpeza de Revisão Online? | Isso depende do horário comercial e dos padrões de tráfego da presença online 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 do AEM (farm TarMK), as janelas de manutenção para limpeza de revisão online devem ser escalonadas. | |
Existem pré-requisitos 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 estiver usando uma versão mais antiga do AEM, será necessário migrar para o novo Oak Segment Tar. |
|
Quais são os fatores que determinam a duração da Limpeza de Revisão Online? | Os fatores são:
|
|
Os autores ainda podem trabalhar enquanto a Limpeza de Revisão Online estiver em execução? | 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 de Limpeza de Revisão Online para um tempo relativamente silencioso sem muito tráfego. | |
Quais são os requisitos mínimos para espaço em disco e memória heap ao executar a Limpeza de Revisão Online? | 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 bem o suficiente para lidar com os casos de uso e a carga esperada nela, 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 em operações normais do sistema. Em particular, pode ser necessário adquirir acesso exclusivo ao repositório por um curto período de tempo, impedindo que outros threads gravem o repositório. | |
Por 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? |
|
|
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 a execução. Isso pode ser o caso se mais tarefas de manutenção do que a Limpeza de Revisão Online forem executadas na 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 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 efetivamente que, se o tamanho do repositório não crescer 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 de log relevantes para a fase de estimativa:
|
|
É possível suspender com segurança a compactação automática se o impacto no desempenho for muito alto? | Sim. Desde o AEM 6.3, ele pode ser interrompido com segurança pela Janela Tarefa de Manutenção no Painel de Operações ou por meio de JMX. | |
Se a instância de AEM for desligada durante uma tarefa de limpeza agendada, o processo aborta com segurança ou o desligamento é bloqueado até que a compactação tenha terminado? | A limpeza da revisão será interrompida e o repositório será desligado com segurança. | |
O que acontece quando o sistema falha 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 da não execução da Limpeza de Revisão Online? | Degradação de desempenho ao longo do tempo. | |
Quais revisões estão sendo coletadas? | Por padrão, a Limpeza de Revisão Online coleta revisões que têm pelo menos 24 horas. | |
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 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á no modo forceCompact, conforme explicado em 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:
|
|
Como a Limpeza de Revisão Online é executada em uma instância de standby? |
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 liberar mais espaço em disco do que a Limpeza de Revisão Online? | 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 this chapter. |
|
Alguma consideração sobre operações de arquivos mapeados de memória? |
|
|
O que precisa ser monitorado durante a Limpeza de Revisão Online? |
|
|
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 logs. Por exemplo, " Correspondentemente, há uma mensagem " |
|
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 ( O progresso pode ser rastreado por meio do atributo Você pode obter uma referência do MBean usando o 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 de AEM para anexar verificações de integridade ao Nagios como um exemplo para uma ferramenta de monitoramento externo. |
|
Quais são as entradas de log relevantes? |
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 log no final do ciclo de limpeza: "TarMK GC #3: cleanup completed " que inclui o tamanho do repositório e a quantidade de lixo recuperada. |
|
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:
|
|
Como detectar se a Limpeza de Revisão Online falhou e quais são as etapas para recuperação? | As condições de falha são marcadas por mensagens de log AVISO ou ERRO, começando 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 Revisão de Limpeza? Como e quando eles contribuem para os níveis de status do código de cores? | A Verificação de Integridade da Revisão de Limpeza faz parte do Painel de Operações. O status será VERDE se a última execução da tarefa de manutenção de Limpeza de Revisão Online tiver sido concluída com êxito. Será AMARELO se a tarefa de manutenção de Limpeza de Revisão Online tiver sido cancelada uma vez. Será RED se a tarefa de manutenção da Limpeza de Revisão Online tiver sido cancelada três vezes seguidas. Nesse caso, a interação manual é necessária, ou a Limpeza de Revisão Online provavelmente falhará novamente. Para obter mais informações, leia a seção 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 de AEM para anexar verificações de integridade ao Nagios como um exemplo para uma ferramenta de monitoramento externo. |
|
Como monitorar a limpeza automática em uma instância de standby? |
O status, o progresso e as estatísticas são expostos via JMX usando o MBean Você pode obter uma referência do MBean usando o 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. Além disso, consulte a documentação de AEM para anexar verificações de integridade ao Nagios como um 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 de standby? |
|
Qual é o pior que pode acontecer se você não executar a Limpeza de Revisão Online? | A instância de AEM ficará sem espaço em disco, o que causará interrupções na produção. | |
O alto tráfego de usuários é problemático para executar a Limpeza de Revisão Online em uma instância de publicação? | O alto tráfego do usuário 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 de log, a Limpeza de Revisão Online não foi concluída com êxito três vezes seguidas. O que é necessário para concluir com sucesso a Limpeza de Revisão Online? | Você pode adotar várias etapas para encontrar e corrigir o problema:
|
|
O que precisa ser feito quando o alerta Healthcheck 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 Online será cancelada e os remanescentes serão removidos. Ele será reiniciado na próxima vez que a janela de manutenção for agendada. | |
O que está fazendo com que as instâncias SegmentNotFoundException sejam registradas no error.log e como posso recuperar? |
Um
|
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. | Habilite a Limpeza de Revisão Online. |
TarMK GC nº 2: estimativa interrompida: ${REASON}. Ignorando compactação. | A fase de estimativa terminou prematuramente. Alguns exemplos de eventos que podem interromper a fase de estimativa: não há memória ou espaço em disco suficiente no sistema host. | Depende do motivo especificado. | |
Compactação | TarMK GC nº 2: compactação pausada | Desde que a fase de compactação seja pausada pela configuração, nem a fase de estimativa nem a fase de compactação serão executadas. | Habilite a limpeza de revisão online. |
TarMK GC nº 2: compactação cancelada: ${REASON}. | A fase de compactação terminou prematuramente. Alguns exemplos de eventos que podem interromper a fase de compactação: não há memória ou espaço em disco suficiente no sistema host. Além disso, a compactação também pode ser cancelada ao desligar o sistema ou ao cancelar explicitamente o sistema por meio de interfaces administrativas, como a Janela de manutenção no Painel de operações. | Depende do motivo especificado. | |
TarMK GC nº 2: a compactação falhou em 32,902 min (1974140 ms), após 5 ciclos | Esta 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 de Limpeza de Revisão Online. | |
Limpar | TarMK GC nº 2: limpeza interrompida | A limpeza foi cancelada ao encerrar o repositório. Não é esperado qualquer impacto na consistência. Além disso, é provável que o espaço em disco não seja recuperado na íntegra. Ele será recuperado durante o próximo ciclo de limpeza de revisão. | Investigue por que o repositório foi desligado e, a partir de agora, tente evitar desligar o repositório durante as janelas de manutenção. |
Diferentes versões da ferramenta Oak-run precisam ser usadas, dependendo da versão do Oak usada com sua instalação do AEM. Verifique a lista de requisitos de versão abaixo antes de usar a ferramenta:
Para versões do Oak 1.0.0 até 1.0.11 ou 1.1.0 até 1.1.6, use a versão Oak-run 1.0.11
Para versões do Oak mais recentes do que o acima, use a versão do Oak-run que corresponde ao núcleo do Oak de sua instalação AEM.
O Adobe fornece uma ferramenta chamada Oak-run para executar a 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 adequadamente. Certifique-se de planejar a limpeza de acordo com sua janela de manutenção.
Para obter dicas sobre como aumentar o desempenho do processo de limpeza, consulte Aumentar o desempenho da limpeza de revisão offline.
Você também pode limpar pontos de verificação antigos antes que a manutenção ocorra (etapas 2 e 3 no procedimento abaixo). Isso é recomendado somente para instâncias com mais de 100 pontos de verificação.
Sempre verifique se você tem um backup recente da instância de AEM.
Desligue AEM.
(Opcional) Use a ferramenta para encontrar pontos de verificação antigos:
java -jar oak-run.jar checkpoints install-folder/crx-quickstart/repository/segmentstore
(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
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
A ferramenta oak-run apresenta vários recursos que visam aumentar o desempenho do processo de limpeza de 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 da memória será usado. Se definido como false, o acesso ao arquivo será usado. Se não especificado, o acesso mapeado à memória é usado em sistemas de 64 bits e o acesso a arquivos é 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.
-Dcompress-range. Número de entradas do mapa de compactação a serem mantidas até compactar o mapa atual. O padrão é 1000000. Você deve aumentar esse valor para um número ainda mais alto para uma taxa de transferência 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 isso junto 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. Requer a ferramenta oak-run versões 1.4 e superiores. 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 segmento não correspondente.
Usar o parâmetro --force
atualizará o armazenamento de segmentos para a versão mais recente, que é incompatível com versões mais antigas do Oak. Além disso, considere que não é possível fazer 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>
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:
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? |
|
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 em 8 horas e o despejos de thread revelar que o ponto de acesso principal é InMemoryCompactionMap.findEntry , use o seguinte parâmetro com a ferramenta oak-run versões 1.4 ou superior: -Dtar.PersistCompactionMap=true . Esteja ciente de que o parâmetro -Dtar.PersistCompactionMap foi removido no Oak versão 1.6. |