Avamar v7 e posterior : a coleta de lixo informa "skipped-hashes" que não podem ser limpos devido a "Hash Referenced Bit Maps" quando os dados estão em uso

O recurso Hash Referenced Bit Maps é um recurso introduzido com o recurso Avamar v7.x que permite que os backups ocorram durante a atividade de manutenção da coleta de lixo (GC). 

Antes desse recurso, a coleta de lixo não podia ser executada simultaneamente devido à possibilidade de conflitos de dados. 

Durante a fase de coleta de lixo, o novo recurso mantém informações na memória sobre os dados que são adicionados ou alterados (um "mapa de hashes referenciados"). A coleta de lixo verifica essas informações para saber quais hashes (e os dados que eles fazem referência) não devem ser removidos.  

Um requisito desse recurso é que esses "mapas" precisem de pelo menos 5 minutos de tempo "silencioso" durante o qual nenhum backup ocorre para que possam ser redefinidos. Assim que essa redefinição ocorrer, os dados que foram bloqueados neles poderão ser examinados durante o ciclo subsequente de coleta de lixo, desde que eles continuem inalterados.

Esse tempo silencioso deve ser considerado ao projetar o agendamento diário de backup e manutenção do Avamar. 
Uma incapacidade dos mapas de redefinir pode impedir a coleta de lixo de limpar dados expirados.
Se o mapa de hash referenciado não tiver a oportunidade de redefinir, os dados que devem ser elegíveis para remoção por lixo não serão processados e o uso da capacidade poderá aumentar. Se o mapa não puder ser redefinido por um longo período, o registro de coleta de lixo poderá mostrar uma quantidade cada vez maior de "hashes ignorados".

Os backups expiraram, mas a coleta de lixo não recuperou todos os dados elegíveis para exclusão porque alguns dos dados eram usados no momento.

Para verificar isso, execute o comando abaixo:
O comando despeja o registro de manutenção da coleta de lixo por 7 dias e o analisa para mostrar.

• Quantos hashes foram ignorados,
• Quantos dados foram excluídos
• Quantas passagens de coleta de lixo foram realizadas
• Por quanto tempo a coleta de lixo foi executada

dumpmaintlogs --types=gc --days=7 | grep passes | cut -d ' ' -f1,10,14,15,17

2014/02/11-11:03:23.01310 skipped-hashes="3118" megabytes-recovered="120" passes="10" elapsed-time="134"
2014/02/12-11:05:33.78790 skipped-hashes="4051" megabytes-recovered="88" passes="10" elapsed-time="264"
2014/02/12-16:18:16.79236 skipped-hashes="5098" megabytes-recovered="199" passes="16" elapsed-time="268"
2014/02/12-16:28:20.35698 skipped-hashes="5099" megabytes-recovered="0" passes="1" elapsed-time="97"
2014/02/12-17:14:22.88473 skipped-hashes="5452" megabytes-recovered="26" passes="20" elapsed-time="162"
2014/02/12-20:46:06.80518 skipped-hashes="6789" megabytes-recovered="83" passes="21" elapsed-time="184"
2014/02/12-21:09:30.70374 skipped-hashes="89139" megabytes-recovered="9432" passes="26" elapsed-time="536"
2014/02/12-23:30:13.07016 skipped-hashes="96510" megabytes-recovered="604" passes="21" elapsed-time="210"
2014/02/12-23:34:15.11324 skipped-hashes="96511" megabytes-recovered="1" passes="3" elapsed-time="99"
2014/02/13-13:41:02.20624 skipped-hashes="97301" megabytes-recovered="0" passes="1" elapsed-time="81"
2014/02/14-11:03:45.31704 skipped-hashes="98220" megabytes-recovered="131" passes="2" elapsed-time="157"
2014/02/14-16:49:14.94905 skipped-hashes="98220" megabytes-recovered="67" passes="2" elapsed-time="105"
2014/02/14-21:15:27.77268 skipped-hashes="98224" megabytes-recovered="0" passes="1" elapsed-time="106"
2014/02/14-21:25:51.71154 skipped-hashes="98224" megabytes-recovered="0" passes="1" elapsed-time="101"
2014/02/14-22:07:19.81136 skipped-hashes="98229" megabytes-recovered="0" passes="1" elapsed-time="125"
2014/02/14-22:15:21.50825 skipped-hashes="98275" megabytes-recovered="1" passes="5" elapsed-time="115"
2014/02/14-22:27:13.88500 skipped-hashes="98278" megabytes-recovered="0" passes="1" elapsed-time="98"
2014/02/14-23:58:47.70116 skipped-hashes="102294" megabytes-recovered="1" passes="4" elapsed-time="110"
2014/02/15-11:02:29.45054 skipped-hashes="102538" megabytes-recovered="0" passes="1" elapsed-time="82"
2014/02/16-00:56:27.25596 skipped-hashes="0" megabytes-recovered="900395" passes="59" elapsed-time="17417"
2014/02/17-11:32:42.66479 skipped-hashes="0" megabytes-recovered="57540" passes="28" elapsed-time="1890"

Análise:

O resultado mostra o número de hashes ignorados aumentando ao longo do tempo até que o mapa referenciado por hash seja redefinido em 16 de fevereiro de 2014.
Também podemos ver o volume de dados limpos "megabytes recuperados" pular depois que os hashes são liberados e a coleta de lixo pode processá-los para dados expirados.

Solução imediata

1. Certifique-se de que os mapas possam ser redefinidos e permitir que a coleta de lixo seja executada novamente.
2. Certifique-se de que não haja sessões avtar em execução adicionando dados ao sistema (dados de backup ou replicação recebida). Use o Monitor de atividade da GUI e verifique se há sessões travadas vistas apenas com o comando "avmaint sessions --full".
3. Interrompa todos os backups e sessões de replicação recebidas.
4. Aguarde pelo menos cinco minutos para permitir que os mapas de bits referenciados por hash tenham tempo suficiente para serem redefinidos.  
5. Quando o GC for executado novamente, verifique o registro de manutenção do GC para confirmar que skipped-hashes=0

Se skipped-hashes não tiver sido redefinido para zero, trabalhe com o suporte para verificar novamente as etapas acima. Se a coleta de lixo MSG_ERR_TRYAGAINLATER, o suporte pode confirmar se isso ocorre devido à atividade de divisão da fração de índice. 
 

Solução de longo prazo

Projete os agendamentos de backup e manutenção para que haja "ocioso" regular disponível para que o mapa de bits referenciado por hash seja redefinido.

Em outras palavras, os agendamentos de backup não devem estar em execução 24/7. Crie um agendamento que ofereça um curto período quando nenhum backup ou dados de replicação recebidos estão sendo gravados no sistema. 

Notas: 

• A única vez que os mapas de bits referenciados por hash verificarão se podem ser redefinidos é logo após o fim de uma sessão avtar. Quando nenhuma sessão avtar estiver em andamento, o mapa só será redefinido se:

• Um motivo pelo qual a contagem de hashes ignorados pode ser temporariamente alta é devido à divisão da fração de índice. Isso ocorre porque os hashes que são movidos para o destino dividido são protegidos. A divisão da fração de índice ocorre em sistemas que ainda estão crescendo ou sendo preenchidos com dados. 
• A coleta de lixo também pode falhar MSG_ERR_TRYAGAINLATER quando as frações de índice estão se dividindo:  
• O MCS pode não estar necessariamente ciente de todas as sessões avtar que ocorrem no servidor Avamar.