Coleta de lixo do armazenamento de dados

Quando um ativo WCM convencional é removido, a referência ao registro do armazenamento de dados subjacente pode ser removida da hierarquia do nó, mas o próprio registro do armazenamento de dados permanece. Esse registro de armazenamento de dados não referenciado se torna "lixo" que não precisa ser retido. Nos casos em que existem vários ativos de lixo, é útil livrar-se deles para preservar espaço e otimizar o desempenho de backup e manutenção do sistema de arquivos.

Na maioria das vezes, um aplicativo WCM tende a coletar informações, mas não excluir informações quase com frequência. Embora novas imagens sejam adicionadas, mesmo após a substituição de versões antigas, o sistema de controle de versão ainda mantém a antiga e oferece suporte para reverter para ela, se necessário. Assim, a maior parte do conteúdo que consideramos ser acrescentado ao sistema é efetivamente armazenada permanentemente. Então, qual é a fonte típica de "lixo" no repositório que podemos querer limpar?

O AEM usa o repositório como o armazenamento para várias atividades internas e domésticas:

  • Pacotes criados e baixados
  • Arquivos temporários criados para a replicação de publicação
  • Cargas do workflow
  • Ativos criados temporariamente durante a renderização do DAM

Quando qualquer um desses objetos temporários for grande o suficiente para exigir armazenamento no armazenamento de dados e, quando o objeto eventualmente deixar de ser usado, o próprio registro do armazenamento de dados permanecerá como "lixo". Em um aplicativo típico de criação/publicação do WCM, a maior fonte de lixo desse tipo geralmente é o processo de ativação de publicação. Quando os dados estão sendo replicados para Publicar, eles são coletados primeiro em coleções em um formato de dados eficiente chamado "Durbo" e armazenados no repositório em /var/replication/data. Geralmente, os pacotes de dados são maiores do que o limite de tamanho crítico para o armazenamento de dados e, portanto, acabam armazenados como registros do armazenamento de dados. Quando a replicação é concluída, o nó em /var/replication/data é excluído, mas o registro do armazenamento de dados permanece como "lixo".

Outra fonte de lixo recuperável são os pacotes. Os dados do pacote, como todo o resto, são armazenados no repositório e, portanto, para pacotes maiores que 4 KB, no armazenamento de dados. Durante um projeto de desenvolvimento ou ao longo do tempo, mantendo um sistema, os pacotes podem ser criados e reconstruídos várias vezes, cada build resultando em um novo registro de armazenamento de dados, órfando o registro da build anterior.

Como a coleta de lixo do armazenamento de dados funciona?

Se o repositório tiver sido configurado com um armazenamento de dados externo, a coleta de lixo do armazenamento de dados será executada automaticamente como parte da Janela de manutenção semanal. O administrador do sistema também pode executar a coleta de lixo do armazenamento de dados manualmente conforme necessário. Em geral, é recomendável que a coleta de lixo do armazenamento de dados seja executada periodicamente, mas os seguintes fatores devem ser considerados no planejamento das coleções de lixo do armazenamento de dados:

  • As coleções de lixo do armazenamento de dados levam tempo e podem afetar o desempenho, portanto, devem ser planejadas adequadamente.
  • A remoção de registros de lixo do armazenamento de dados não afeta o desempenho normal, portanto, isso não é uma otimização de desempenho.
  • Se a utilização do armazenamento e os fatores relacionados como os tempos de backup não forem motivo de preocupação, a coleta de lixo do armazenamento de dados poderá ser adiada com segurança.

O coletor de lixo do armazenamento de dados primeiro anota o carimbo de data e hora atual quando o processo começa. A coleção é então realizada usando um algoritmo de padrão de marca/varredura de vários passos.

Na primeira fase, o coletor de lixo do armazenamento de dados realiza uma ampla travessia de todo o conteúdo do repositório. Para cada objeto de conteúdo que tenha uma referência a um registro de armazenamento de dados, ele localizou o arquivo no sistema de arquivos, executando uma atualização de metadados — modificando o atributo "última modificação" ou MTIME. Nesse ponto, os arquivos acessados por essa fase se tornam mais recentes do que o carimbo de data e hora da linha de base inicial.

Na segunda fase, o coletor de lixo do armazenamento de dados atravessa a estrutura do diretório físico do armazenamento de dados da mesma forma que um "find". Examinou o atributo "última modificação" ou MTIME do ficheiro e faz a seguinte determinação:

  • Se o MTIME for mais recente do que o carimbo de data e hora da linha de base inicial, o arquivo foi encontrado na primeira fase ou é um arquivo totalmente novo que foi adicionado ao repositório enquanto o processo de coleta estava em andamento. Em qualquer destes casos, o registro é considerado ativo e o processo não é suprimido.
  • Se o MTIME for anterior ao carimbo de data e hora da linha de base inicial, o arquivo não será um arquivo ativamente referenciado e será considerado um lixo removível.

Essa abordagem funciona bem em um único nó com um armazenamento de dados privado. No entanto, o armazenamento de dados pode ser compartilhado e, se for esse o caso, as referências ativas potencialmente ativas para registros de armazenamento de dados de outros repositórios não são verificadas e os arquivos referenciados ativos podem ser removidos por engano. É fundamental que o administrador do sistema entenda a natureza compartilhada do armazenamento de dados antes de planejar qualquer coleta de lixo e use apenas o processo de coleta de lixo do armazenamento de dados integrado simples quando for sabido que o armazenamento de dados não é compartilhado.

OBSERVAÇÃO

Ao executar a coleta de lixo em uma configuração de armazenamento de dados em cluster ou compartilhado (com Mongo ou Segment Tar), o log pode exibir avisos sobre a incapacidade de excluir determinadas IDs de blob. Isso ocorre porque as IDs de blob excluídas em uma coleção de lixo anterior são referenciadas incorretamente novamente por outro cluster ou nós compartilhados que não têm informações sobre as exclusões de ID. Como resultado, quando a coleta de lixo é executada, ela registra um aviso ao tentar excluir uma ID que já foi excluída na última execução. Esse comportamento não afeta o desempenho ou a funcionalidade.

Executando a Coleta de Lixo do Data Store

Há três maneiras de executar a coleta de lixo do armazenamento de dados, dependendo da configuração do armazenamento de dados em que o AEM está sendo executado:

  1. Por meio de Revisão de limpeza - um mecanismo de coleta de lixo normalmente usado para limpeza de armazenamento de nó.

  2. Por meio de Data Store Garbage Collection - um mecanismo de coleta de lixo específico para armazenamentos de dados externos, disponível no Painel de Operações.

  3. Através do Console JMX.

Se TarMK estiver sendo usado como armazenamento de nó e armazenamento de dados, a Limpeza de Revisão poderá ser usada para coleta de lixo do armazenamento de nó e do armazenamento de dados. No entanto, se um armazenamento de dados externo estiver configurado, como File System Data Store, a coleta de lixo do armazenamento de dados deverá ser explicitamente acionada separadamente da Limpeza de revisão. A coleta de lixo do armazenamento de dados pode ser acionada pelo Painel de operações ou pelo Console JMX.

A tabela abaixo mostra o tipo de coleta de lixo do armazenamento de dados que precisa ser usado para todas as implantações do armazenamento de dados com suporte no AEM 6:

Armazenamento de nós
Armazenamento de dados Mecanismo de coleta de lixo
TarMK TarMK Limpeza de revisão (os binários são alinhados com a Loja de segmentos)
TarMK Sistema de arquivos externo

Tarefa de coleta de lixo do armazenamento de dados por meio do Painel de operações

Console JMX

MongoDB MongoDB

Tarefa de coleta de lixo do armazenamento de dados por meio do Painel de operações

Console JMX

MongoDB Sistema de arquivos externo

Tarefa de coleta de lixo do armazenamento de dados por meio do Painel de operações

Console JMX

Execução da coleta de lixo do armazenamento de dados por meio do Painel de operações

A Janela de manutenção semanal integrada, disponível por meio do Operations Dashboard, contém uma tarefa incorporada para acionar a coleta de lixo do armazenamento de dados às 1:00 dos domingos.

Se precisar executar a coleta de lixo do armazenamento de dados fora desse tempo, ela poderá ser acionada manualmente pelo Painel de operações.

Antes de executar a coleta de lixo do armazenamento de dados, verifique se não há backups em execução no momento.

  1. Abra o Painel de Operações por Navegação -> Ferramentas -> Operações -> Manutenção.

  2. Clique ou toque na Janela de manutenção semanal.

    chlimage_1-64

  3. Selecione a tarefa Data Store Garbage Collection e clique ou toque no ícone Run.

    chlimage_1-65

  4. A coleta de lixo do armazenamento de dados é executada e seu status é exibido no painel.

    chlimage_1-66

OBSERVAÇÃO

A tarefa Coleta de lixo do armazenamento de dados só estará visível se você tiver configurado um armazenamento de dados de arquivo externo. Consulte Configuração de armazenamentos de nó e armazenamentos de dados em AEM 6 para obter informações sobre como configurar um armazenamento de dados de arquivo.

Execução da coleta de lixo do armazenamento de dados por meio do console JMX

Esta seção trata da execução manual da coleta de lixo do armazenamento de dados por meio do Console JMX. Se a instalação estiver configurada sem um armazenamento de dados externo, isso não se aplica à instalação. Em vez disso, consulte as instruções sobre como executar a limpeza de revisão em Manutenção do Repositório.

OBSERVAÇÃO

Se você estiver executando o TarMK com um armazenamento de dados externo, é necessário executar a Limpeza de Revisão primeiro para que a coleta de lixo seja eficaz.

Para executar a coleta de lixo:

  1. No Console de Gerenciamento OSGi do Apache Felix, realce a guia Main e selecione JMX no menu a seguir.

  2. Em seguida, procure e clique em Gerenciador de Repositório MBean (ou vá para https://<host>:<port>/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Drepository+manager%2Ctype%3DRepositoryManagement).

  3. Clique em startDataStoreGC(boolean markOnly).

  4. digite "true" para o parâmetro markOnly se necessário:

    Opção Descrição
    booleano markOnly Defina como true para marcar apenas referências e não varrer a operação de marcação e varredura. Esse modo deve ser usado quando o BlobStore subjacente for compartilhado entre vários repositórios diferentes. Para todos os outros casos, defina-o como falso para executar a coleta de lixo completa.
  5. Clique em Invoke. O CRX executa a coleta de lixo e indica quando ela foi concluída.

OBSERVAÇÃO

A coleta de lixo do armazenamento de dados não coletará arquivos que foram excluídos nas últimas 24 horas.

OBSERVAÇÃO

A tarefa de coleta de lixo do armazenamento de dados só será iniciada se você tiver configurado um armazenamento de dados de arquivo externo. Se um armazenamento de dados de arquivo externo não tiver sido configurado, a tarefa retornará a mensagem Cannot perform operation: no service of type BlobGCMBean found após invocar. Consulte Configuração de armazenamentos de nó e armazenamentos de dados em AEM 6 para obter informações sobre como configurar um armazenamento de dados de arquivo.

Automatizando a coleta de lixo do armazenamento de dados

Se possível, a coleta de lixo do armazenamento de dados deve ser executada quando houver pouca carga no sistema, por exemplo, pela manhã.

A Janela de manutenção semanal integrada, disponível por meio do Operations Dashboard, contém uma tarefa incorporada para acionar a coleta de lixo do armazenamento de dados às 1:00 dos domingos. Você também deve verificar se nenhum backup está sendo executado no momento. O início da janela de manutenção pode ser personalizado por meio do painel, conforme necessário.

OBSERVAÇÃO

O motivo para não executá-lo simultaneamente é para que os arquivos de armazenamento de dados antigos (e não utilizados) também tenham backup, de modo que, se for necessário reverter para uma revisão antiga, os binários ainda estarão lá no backup.

Se você não quiser executar a coleta de lixo do armazenamento de dados com a Janela de manutenção semanal no Painel de operações, ela também poderá ser automatizada usando os clientes HTTP wget ou curl. Este é um exemplo de como automatizar o backup usando curl:

CUIDADO

No exemplo a seguir, comandos curl podem ser necessários vários parâmetros para a sua instância; por exemplo, o nome do host ( localhost), a porta ( 4502), a senha do administrador ( xyz) e vários parâmetros para a coleta de lixo do armazenamento de dados real.

Este é um exemplo de comando curl para chamar a coleta de lixo do armazenamento de dados por meio da linha de comando:

curl -u admin:admin -X POST --data markOnly=true  https://localhost:4503/system/console/jmx/org.apache.jackrabbit.oak"%"3Aname"%"3Drepository+manager"%"2Ctype"%"3DRepositoryManagement/op/startDataStoreGC/boolean

O comando curl retorna imediatamente.

Verificando a consistência do armazenamento de dados

A verificação de consistência do armazenamento de dados reportará todos os binários do armazenamento de dados que estão ausentes, mas ainda são referenciados. Para iniciar uma verificação de consistência, siga estas etapas:

  1. Vá para o console JMX. Para obter informações sobre como usar o console JMX, consulte este artigo.
  2. Procure o Mbean BlobGarbageCollection e clique nele.
  3. Clique no link checkConsistency().

Após a conclusão da verificação de consistência, uma mensagem mostrará o número de binários relatados como ausentes. Se o número for maior que 0, verifique error.log para obter mais detalhes sobre os binários ausentes.

Abaixo você encontrará um exemplo de como os binários ausentes são relatados nos logs:

11:32:39.673 INFO [main] MarkSweepGarbageCollector.java:600 Consistency check found [1] missing blobs
11:32:39.673 WARN [main] MarkSweepGarbageCollector.java:602 Consistency check failure intheblob store : DataStore backed BlobStore [org.apache.jackrabbit.oak.plugins.blob.datastore.OakFileDataStore], check missing candidates in file /tmp/gcworkdir-1467352959243/gccand-1467352959243

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
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now