Coleta de lixo do armazenamento de dados data-store-garbage-collection
Quando um ativo WCM convencional é removido, a referência ao registro de armazenamento de dados subjacente pode ser removida da hierarquia do nó, mas o próprio registro de armazenamento de dados permanece. Esse registro de armazenamento de dados não referenciado torna-se "lixo", que não precisa ser retido. Nos casos em que existem vários ativos de lixo, é benéfico eliminá-los 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 a excluí-las com quase frequência. Embora novas imagens sejam adicionadas, mesmo substituindo versões antigas, o sistema de controle de versão ainda retém a antiga e permite a reversão para ela, se necessário. Dessa forma, a maior parte do conteúdo que adicionamos ao sistema é 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 armazenamento para várias atividades internas e de manutenção do sistema:
- Pacotes criados e baixados
- Arquivos temporários criados para replicação de publicação
- Cargas de fluxo de trabalho
- Assets criado temporariamente durante a renderização do DAM
Quando qualquer um desses objetos temporários é grande o suficiente para exigir armazenamento no armazenamento de dados e quando o objeto eventualmente passa para fora de uso, o próprio registro do armazenamento de dados permanece como "lixo". Em um aplicativo WCM típico de criação/publicação, a maior fonte de lixo desse tipo é geralmente o processo de ativação de publicação. Quando os dados estiverem sendo replicados para o Publish, eles serão coletados pela primeira vez em coleções em um formato de dados eficiente chamado "Durbo" e armazenados no repositório em /var/replication/data. Os pacotes de dados geralmente são maiores que o limite de tamanho crítico do armazenamento de dados e, portanto, são armazenados como registros de 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 tudo o mais, são armazenados no repositório e, portanto, para pacotes com mais de 4 KB, no armazenamento de dados. Durante um projeto de desenvolvimento ou ao longo do tempo enquanto mantém um sistema, os pacotes podem ser criados e recriados muitas vezes, cada criação resultando em um novo registro de armazenamento de dados, tornando-o órfão do registro da criação anterior.
Como funciona a coleta de lixo do armazenamento de dados? how-does-data-store-garbage-collection-work
Se o repositório tiver sido configurado com um repositório de dados externo, a coleta de lixo do repositório 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, recomenda-se que a coleta de lixo do armazenamento de dados seja executada periodicamente, mas que os seguintes fatores sejam considerados no planejamento das coletas de lixo do armazenamento de dados:
- As coletas 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, não é uma otimização de desempenho.
- Se a utilização do armazenamento e fatores relacionados, como tempos de backup, não forem uma 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 faz uma observação do carimbo de data e hora atual quando o processo começa. A recolha é então realizada utilizando um algoritmo de marca multipasso/padrão de varrimento.
Na primeira fase, o coletor de lixo do armazenamento de dados realiza uma passagem abrangente de todo o conteúdo do repositório. Para cada objeto de conteúdo que tem 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 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 uma "localização". Examinou o atributo "last modified" ou MTIME do arquivo e faz a seguinte determinação:
- Se o MTIME for mais recente 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 é apagado.
- Se o MTIME for anterior ao carimbo de data e hora da linha de base inicial, o arquivo não é um arquivo referenciado ativamente e é considerado lixo removível.
Essa abordagem funciona bem para um único nó com um armazenamento de dados privado. No entanto, o armazenamento de dados pode ser compartilhado e, se for, significa que as referências potencialmente ativas para registros do 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 o processo simples de coleta de lixo do armazenamento de dados integrado quando for conhecido que o armazenamento de dados não é compartilhado.
Executando Coleta de Lixo do Repositório 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 no qual o AEM está sendo executado:
-
Via Limpeza de Revisão - um mecanismo de coleta de lixo geralmente usado para limpeza de armazenamento de nós.
-
Por meio da Coleta de Lixo do Repositório de Dados - um mecanismo de coleta de lixo específico para repositórios de dados externos, disponível no Painel de Operações.
-
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 a coleta de lixo do armazenamento de nó e do armazenamento de dados. No entanto, se um armazenamento de dados externo estiver configurado, como o Armazenamento de dados do sistema de arquivos, a coleta de lixo do armazenamento de dados deverá ser acionada explicitamente, separado 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 de armazenamento de dados compatíveis com o 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 interna, disponível no Painel de Operações, contém uma tarefa interna para acionar a Coleta de Lixo do Repositório de Dados às 1:00 aos domingos.
Se você precisar executar a coleta de lixo do armazenamento de dados fora desse período, ela poderá ser acionada manualmente por meio do Painel de operações.
Antes de executar a coleta de lixo do armazenamento de dados, você deve verificar se nenhum backup está em execução no momento.
-
Abra o Painel de Operações por Navegação > Ferramentas > Operações > Manutenção.
-
Clique na Janela de manutenção semanal.
-
Selecione a tarefa Coleta de Lixo do Repositório de Dados e clique no ícone Executar.
-
A coleta de lixo do armazenamento de dados é executada e seu status é exibido no painel.
Executando a 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 sua instalação for configurada sem um armazenamento de dados externo, isso não se aplica à sua instalação. Em vez disso, consulte 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 guia Principal e selecione JMX no menu a seguir.
-
Em seguida, pesquise por e clique no 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).
-
insira "
true" para o parâmetromarkOnly, se necessário:table 0-row-2 1-row-2 Opção Descrição boolean markOnly Defina como verdadeiro para marcar somente as referências e não varrer na 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 como falso para executar a coleta de lixo completa. -
Clique em Chamar. 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 Configurando 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, de manhã.
A Janela de Manutenção Semanal interna, disponível no Painel de Operações, contém uma tarefa interna para acionar a Coleta de Lixo do Repositório de Dados às 1:00 aos domingos. Você também deve verificar se não há backups em execução 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 a coleta de lixo usando o curl:
curl, vários parâmetros podem precisar ser configurados para sua instância; por exemplo, o nome do host ( localhost), a porta ( 4502), a senha de 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 pela 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 checking-data-store-consistency
A verificação de consistência do armazenamento de dados relatará todos os binários de 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 Recursos do Monitoring Server Usando o Console JMX.
- Procure o Mbean BlobGarbageCollection e clique nele.
- 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 o 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