Como monitorar o TarMK | AEM 6.3 | OAK 1.6

*As informações a seguir são aplicáveis para o Oak versão 1.6 e superiores e o AEM 6.3 e superiores.

Problema
Devido à memória disponível limitada (off e on heap), quando o repositório da instância cresce em um determinado nível, os caches ficam sobrecarregados.
Como resultado, a maioria dos acessos ao repositório lê dados diretamente do disco, o que é muito mais lento, resultando em uma experiência ruim do usuário final.

Sintomas
No geral, a instância se torna lenta: o tempo de resposta aumenta e a Limpeza de Revisão Online leva muito mais tempo para ser concluída, às vezes ultrapassando a janela de manutenção alocada.
No nível do sistema, uma alta atividade constante de E/S é observada.

Etapas

Solução de problemas

Existem vários endpoints que são monitorados para determinar quando o sistema se torna IO bound. 
Os parágrafos a seguir discutem os endpoints disponíveis e os principais indicadores.

Monitorando endpoints

Existem vários endpoints para monitorar métricas relacionadas a E/S no AEM, na JVM e no SO. 

Juntos, eles fornecem diferentes perspectivas sobre a taxa de transferência geral no sistema nas várias camadas: das sessões do JCR ao commit no TarMK à E/S no disco no TarMK.

Combinado com informações coletadas com ferramentas de nível de sistema operacional e JVM, elas fornecem uma riqueza de informações sobre a integridade do sistema e ajudam a encontrar gargalos.

• Cada sessão expõe uma instância SessionMBean, que contém contadores como o número e a taxa de leituras e gravações na sessão.
• O RepositoryStatsMBean expõe endpoints para monitorar o número de sessões abertas, a taxa de login da sessão, a carga geral de leitura e gravação em todas as sessões, os intervalos gerais de leitura e gravação em todas as sessões e a carga e intervalos gerais para consultas e observação.
• O SegmentNodeStoreStatsMBean expõe endpoints para monitorar commits: número e taxa, número de commits na fila e tempos de enfileiramento.
• O FileStoreStatsMBean expõe endpoints que refletem a quantidade de dados gravados no disco, o número de arquivos tar no disco e a footprint total no disco.

Além desses endpoints, existem muitas ferramentas específicas da JVM e do SO que ajudam a obter mais informações sobre com o que o sistema está ocupado:

• Java Mission Control (jmc) é uma ferramenta poderosa para coletar todos os aspectos de desempenho de uma JVM em execução. Sua capacidade de gravar E/S por processo Java às vezes pode ser inestimável.
• As ferramentas de linha de comando jstat, jstack, e jmap são úteis para entrar no coletor de lixo da JVM, nos encadeamentos da JVM e no heap da JVM, respectivamente.
• As ferramentas a nível de sistema operacional vmstat e iostat são usados para examinar E/S e o uso de CPU no nível do sistema operacional.

Monitorando E/S de disco

O que: o número de operações de disco (leituras/gravações) por unidade de tempo (segundo)

Como: ferramentas de nível de sistema operacional (por exemplo: vmstat, iostat no UNIX)

Normal: nível baixo de leituras de disco (perto de zero); baixo e constante número de gravações (veja a imagem). Picos durante a limpeza da revisão.

Aviso: nível alto e crescente de leituras de disco é um sinal de subdimensionamento de memória (veja a imagem).

AVISO: um volume alto de E/S de disco deve-se a outras operações em execução no AEM (por exemplo: ingestão de ativos) ou por outro processo (por exemplo: verificação de vírus), portanto, exclua qualquer outra causa antes de diagnosticar o Segment Tar como culpado. Geralmente, a tendência ao longo dos dias é mais relevante do que os picos locais.

Monitorando a CPU

• O que: tempo gasto pela CPU para várias operações, especialmente esperando por E/S.
• Como: ferramentas de nível de sistema operacional (por exemplo: vmstat no UNIX). Nem todas as ferramentas relatam isso (por exemplo: acima).
• Normal: A CPU é usada principalmente pelo aplicativo a nível do usuário e a espera por E/S é uma pequena porcentagem.
• Aviso: A CPU está gastando a maior parte dos ciclos aguardando a E/S, com uma tendência crescente, em detrimento do aplicativo do usuário.
• AVISO: uma alta porcentagem de CPU esperando por E/S deve-se a outras operações em execução no AEM (por exemplo: ingestão de ativos) ou por outro processo (por exemplo: verificação de vírus), portanto, exclua qualquer outra causa antes de diagnosticar o Segment Tar como culpado. Geralmente, a tendência ao longo dos dias é mais relevante do que os picos locais.

Monitorando a fila de commit

• O que: a fila de commit é um mecanismo de armazenamento em buffer usado pelo Segment Tar quando o volume de entrada de commits é maior que a velocidade de processamento.
• Como: o tamanho da fila de commit em tempo real é exposto por meio do JMX MBean: org.apache.jackrabbit.oak: COMMIT_QUEUE_SIZE (Metrics) (/system/console/jmx/org.apache.jackrabbit.oak%3Aname%3DCOMMIT_QUEUE_SIZE%2Ctype%3DMetrics). Ele é acessado via http no console do sistema ou usando um cliente JMX.
• Normal: uma fila vazia (size=0) mostra que o sistema está em um estado íntegro e pode processar todos os commits na velocidade em que eles entram. Picos locais que são processados rapidamente também são normais.
• Aviso: fila constante, diferente de zero, com uma tendência crescente significa que o segment tar não pode processar os commits na sua velocidade de entrada. Existe o risco de a fila ficar cheia e os novos commits serem rejeitados.
• AVISO: uma fila alta temporária (pico) deve-se a uma operação intensiva que está sendo acionada (por exemplo: replicação ou roll-out) ou tráfego alto, portanto, certifique-se de excluir qualquer outra causa antes de diagnosticar o Segment Tar como o culpado. Geralmente a tendência é mais relevante do que os picos locais.