Coleta de lixo do armazenamento de dados data-store-garbage-collection
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 for 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? how-does-data-store-garbage-collection-work
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 sempre que 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.
Execução da coleta de lixo do armazenamento de dados running-data-store-garbage-collection
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:
-
Via Limpeza de Revisão - um mecanismo de coleta de lixo normalmente usado para limpeza de armazenamento de nó.
-
Via Coleta de lixo do armazenamento de dados - um mecanismo de coleta de lixo específico para armazenamentos de dados externos, disponível no Painel de Operações.
-
Por meio 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:
Execução da coleta de lixo do armazenamento de dados por meio do Painel de operações running-data-store-garbage-collection-via-the-operations-dashboard
A janela de manutenção semanal integrada, disponível através do Painel de operaçõesO 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.
-
Abra o Painel de Operações por Navegação -> Ferramentas -> Operações -> Manutenção.
-
Clique ou toque no Janela de manutenção semanal.
-
Selecione o Coleta de lixo do armazenamento de dados e clique ou toque em Executar ícone .
-
A coleta de lixo do armazenamento de dados é executada e seu status é exibido no painel.
Execução da coleta de lixo do armazenamento de dados por meio do console JMX running-data-store-garbage-collection-via-the-jmx-console
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, veja as instruções sobre como executar a limpeza de revisão em Manutenção do repositório.
Para executar a coleta de lixo:
-
No Console de Gerenciamento do Apache Felix OSGi, destaque a Principal e selecione JMX no menu a seguir.
-
Em seguida, procure e clique no botão Gerenciador de Repositório MBean (ou vá para
https://<host>:<port>/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3Drepository+manager%2Ctype%3DRepositoryManagement). -
Clique em startDataStoreGC(boolean markOnly).
-
digite "
true" para omarkOnlyparâmetro se necessário:table 0-row-2 1-row-2 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. -
Clique em Invocar. O CRX executa a coleta de lixo e indica quando ela foi concluída.
Cannot perform operation: no service of type BlobGCMBean found após invocar . Consulte Configuração de armazenamentos de nó e armazenamentos de dados no AEM 6 para obter informações sobre como configurar um armazenamento de dados de arquivo.Automatização da coleta de lixo do armazenamento de dados automating-data-store-garbage-collection
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 através do Painel de operaçõesO 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.
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:
curl comandos podem ser necessários vários parâmetros para a sua instância; por exemplo, o nome de host ( localhost), porta ( 4502), 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 http://localhost:4503/system/console/jmx/org.apache.jackrabbit.oak"%"3Aname"%"3Drepository+manager"%"2Ctype"%"3DRepositoryManagement/op/startDataStoreGC/boolean
O comando curl retorna imediatamente.
Verificar a consistência do armazenamento de dados checking-data-store-consistency
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:
-
Vá para o console JMX. Para obter informações sobre como usar o console JMX, consulte este artigo.
-
Procure a variável Blob GC Mbean e clique nele.
-
Clique no botão
checkConsistency()link .
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 a 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 in the blob store : DataStore backed BlobStore [org.apache.jackrabbit.oak.plugins.blob.datastore.OakFileDataStore], check missing candidates in file /tmp/gcworkdir-1467352959243/gccand-1467352959243