Monitorar e manter sua instância do AEM monitoring-and-maintaining-your-aem-instance

CAUTION
AEM 6.4 chegou ao fim do suporte estendido e esta documentação não é mais atualizada. Para obter mais detalhes, consulte nossa períodos de assistência técnica. Encontre as versões compatíveis here.

Após a implantação de suas instâncias de AEM, determinadas tarefas serão necessárias para monitorar e manter a operação, o desempenho e a integridade.

Um fator importante aqui é que, para reconhecer possíveis problemas, você precisa saber como seus sistemas se parecem e se comportam em condições normais. Isso é feito de forma mais eficaz, monitorando o sistema e coletando informações durante um período de tempo.

Verificar
Considerações
Comentário / Ações
Plano de backup.
Veja como Faça backup da sua instância.
Plano de recuperação de desastres.
As diretrizes de recuperação de desastres de sua empresa.
Um sistema de rastreamento de erros está disponível para problemas de relatório.
Por exemplo, bugzilha, jira, ou um de muitos outros.
Os sistemas de arquivos estão sendo monitorados.
O repositório CRX será "congelado" se não houver espaço livre em disco suficiente. Ele será retomado assim que o espaço estiver disponível.
" *ERROR* LowDiskSpaceBlocker" mensagens podem ser vistas no arquivo de log quando o espaço livre se tornar baixo.
Arquivos de log estão sendo monitoradas.
O monitoramento do sistema está (constantemente) sendo executado em segundo plano.
Incluindo utilização de CPU, memória, disco e rede. Usando, por exemplo, iostat / vmstat / perfmon.
Os dados registrados são visualizados e podem ser usados para rastrear problemas de desempenho. Dados brutos também podem ser acessados.
AEM desempenho está sendo monitorado.
Incluindo Contadores de solicitações para monitorar os níveis de tráfego.
Caso se verifique uma perda significativa ou a longo prazo do desempenho, deve ser efetuado um inquérito pormenorizado.
Você está monitorando seu Agentes de replicação.
Limpar regularmente instâncias de fluxo de trabalho.
Tamanho do repositório e desempenho do workflow.
Consulte Limpeza regular de instâncias de fluxo de trabalho.

Backups backups

É uma boa prática fazer backups de:

  • Instalação do software - antes/depois de alterações significativas na configuração
  • O conteúdo mantido no repositório - regularmente

Sua empresa provavelmente terá uma política de backup que você precisará seguir, considerações adicionais sobre o que fazer backup e quando incluir:

  • a importância do sistema e dos dados.
  • com que frequência as alterações são feitas no software ou nos dados.
  • volume de dados; ocasionalmente, a capacidade pode ser um problema, assim como o tempo necessário para executar o backup.
  • se o backup pode ser feito enquanto os usuários estão online; e, se possível, qual é o impacto no desempenho.
  • A distribuição geográfica dos utilizadores; ou seja, quando é o melhor momento para fazer backup (para minimizar o impacto)?
  • sua política de recuperação de desastres; há diretrizes sobre onde os dados de backup devem ser armazenados (por exemplo, fora do local, meio específico etc.).

Geralmente, um backup completo é feito em intervalos regulares (por exemplo, diariamente, semanalmente ou mensalmente), com backups incrementais entre (por exemplo, a cada hora, diariamente ou semanalmente).

CAUTION
Ao implementar backups de suas instâncias de produção, os testes must para garantir que o backup possa ser restaurado com êxito.
Sem isso, o backup é potencialmente inútil (pior cenário).
NOTE
Para obter mais informações sobre desempenho de backup, leia o Desempenho do backup seção.

Backup da instalação do software backing-up-your-software-installation

Após a instalação ou alterações significativas na configuração, faça um backup da instalação do software.

Para fazer isso, você precisa fazer backup de todo o repositório e depois:

  1. Pare de AEM.
  2. Faça o backup de todo o <cq-installation-dir> do seu sistema de arquivos.
CAUTION
Se você estiver operando um servidor de aplicativos de terceiros, as pastas adicionais podem estar em um local diferente e também podem precisar ser copiadas em backup. Consulte Como instalar o AEM com um servidor de aplicativos para obter informações sobre como instalar servidores de aplicativos.
CAUTION
Há suporte para backup incremental do armazenamento de dados do arquivo; ao usar o backup incremental para outros componentes (como o índice Lucene), verifique se os arquivos excluídos também estão marcados como excluídos no backup.
NOTE
O espelhamento de disco também pode ser usado como um mecanismo de backup.

Backup do repositório backing-up-your-repository

O Backup e restauração A seção da documentação CRX cobre todos os problemas relacionados aos backups do repositório CRX.

Para obter detalhes completos sobre como fazer um backup on-line "em operação", consulte Criação de um backup online.

Limpeza de versão version-purging

O Limpar versões A ferramenta destina-se a limpar as versões de um nó ou uma hierarquia de nós em seu repositório. Seu objetivo principal é ajudar você a reduzir o tamanho do repositório, removendo versões antigas dos nós.

Esta seção trata das operações de manutenção relacionadas ao recurso de controle de versão do AEM. O Limpar versão A ferramenta destina-se a limpar as versões de um nó ou uma hierarquia de nós em seu repositório. Seu objetivo principal é ajudar você a reduzir o tamanho do repositório, removendo versões antigas dos nós.

Visão geral overview

O Limpar versões está disponível na Ferramentas console under Controle de versão ou diretamente em:

https://<server>:<port>/etc/versioning/purge.html

screen_shot_2012-03-15at14418pm

Caminho de início Um caminho absoluto no qual a limpeza deve ser feita. Você pode selecionar Iniciar caminho clicando no navegador da árvore do repositório.

Recursivo Ao limpar dados, você pode escolher entre executar a operação em um nó ou em uma hierarquia inteira selecionando Recursivo. No último caso, o caminho especificado define o nó raiz da hierarquia.

Máximo de versões para manter O número máximo de versões a serem mantidas para um nó. Quando esse número excede esse valor, as versões mais antigas são removidas.

Idade máxima da versão A idade máxima da versão de um nó. Quando a idade de uma versão exceder esse valor, ela será removida.

Execução de prática Como a remoção de versões do seu conteúdo é definitiva e não pode ser revertida sem restaurar um backup, a ferramenta Limpar versões fornece um modo de execução seca que permite que você visualize as versões eliminadas. Para iniciar uma execução seca do processo de limpeza, clique em Execução de prática.

Limpar Inicie a limpeza das versões no nó definido pelo Caminho de início.

Limpeza de versões de um site purging-versions-of-a-web-site

Para limpar versões de um site, proceda da seguinte maneira:

  1. Navegue até o Ferramentas console, selecione Controle de versão e clique duas vezes Limpar versões.

  2. Defina o caminho de início do conteúdo a ser removido (por exemplo, /content/geometrixx-outdoors).

    • Se desejar limpar apenas o nó definido pelo seu caminho, desmarque Recursivo.
    • Se desejar limpar o nó definido pelo seu caminho e seus descendentes, selecione Recursivo.
  3. Defina o número máximo de versões (para cada nó) que deseja manter. Deixe em branco para não usar essa configuração.

  4. Defina a idade máxima da versão em dias (para cada nó) que deseja manter. Deixe em branco para não usar essa configuração.

  5. Clique em Execução de prática para visualizar o que o processo de limpeza faria.

  6. Clique em Limpar para iniciar o processo.

CAUTION
Os nós removidos não podem ser revertidos sem restaurar o repositório. Você deve cuidar da sua configuração, de modo que recomendamos que você sempre execute um exercício de simulação antes de limpar.

Análise do console analyzing-the-console

O Execução de prática e Limpar Os processos listam todos os nós que foram processados. Durante o processo, um nó pode ter um dos seguintes status:

  • ignore (not versionnable): o nó não oferece suporte ao controle de versão e é ignorado durante o processo.
  • ignore (no version): o nó não tem nenhuma versão e é ignorado durante o processo.
  • retained: o nó não é removido.
  • purged: o nó é removido.

Além disso, o console fornece informações úteis sobre as versões:

  • V 1.0: o número da versão.
  • V 1.0.1*: a estrela indica que a versão é a atual.
  • Thu Mar 15 2012 08:37:32 GMT+0100: a data da versão.

No próximo exemplo:

  • O Camisas são removidas porque a idade da versão é superior a 2 dias.
  • O Tonga - Moda! são eliminadas porque o número de versões é maior que 5.

global_version_screenshot

Trabalhar com registros de auditoria e arquivos de registro working-with-audit-records-and-log-files

Registros de auditoria e arquivos de log relacionados ao Adobe Experience Manager (AEM) podem ser encontrados em vários locais. O seguinte é fornecido para fornecer uma visão geral do que pode ser encontrado.

Trabalhar com logs working-with-logs

AEM registros WCM detalhados. Depois de descompactar e iniciar o Quickstart, você pode encontrar logs em:

  • <cq-installation-dir>/crx-quickstart/logs/
  • <cq-installation-dir>/crx-quickstart/repository/

Rotação do arquivo de log log-file-rotation

A rotação do arquivo de log refere-se ao processo que limita o crescimento do arquivo ao criar um novo arquivo periodicamente. No AEM, um arquivo de log chamado error.log será girado uma vez por dia de acordo com as regras fornecidas:

  • O error.log arquivo é renomeado de acordo com o padrão {original_filename} .yyyy-MM-dd. Por exemplo, em 11 de julho de 2010, o arquivo de log atual será renomeado error.log-2010-07-10, em seguida, um novo error.og é criada.
  • Os arquivos de log anteriores não são excluídos, portanto, é sua responsabilidade limpar arquivos de log antigos periodicamente para limitar o uso do disco.
NOTE
Se você atualizar sua instalação AEM, observe que qualquer arquivo de log existente que não for mais usado pelo AEM permanecerá no disco. Você pode removê-los sem riscos. Todas as novas entradas de log serão gravadas nos novos arquivos de log.

Encontrar arquivos de log finding-the-log-files

Vários arquivos de log são mantidos no servidor de arquivos onde você instalou o AEM:

  • <cq-installation-dir>/crx-quickstart/logs

    • access.log

      Todas as solicitações de acesso para AEM WCM e o repositório são registradas aqui.

    • audit.log

      As ações de moderação são registradas aqui.

    • error.log

      Mensagens de erro (de vários níveis de gravidade) são registradas aqui.

    • ImageServer-<PortId>-yyyy>-<mm>-<dd>.log

      Este log é usado somente se a mídia dinâmica estiver ativada. Ele fornece estatísticas e informações analíticas usadas para analisar o comportamento do processo interno do ImageServer.

    • request.log

      Cada solicitação de acesso é registrada aqui junto com a resposta.

    • s7access-<yyyy>-<mm>-<dd>.log

      Este log é usado somente se a mídia dinâmica estiver ativada. O log s7access registra cada solicitação feita ao Dynamic Media por meio de /is/image e /is/content.

    • stderr.log

      Retém mensagens de erro, novamente de vários níveis de gravidade, geradas durante a inicialização. Por padrão, o nível de log é definido como Warning ( WARN)

    • stdout.log

      Mantém mensagens de registro que indicam eventos durante a inicialização.

    • upgrade.log

      Fornece um log de todas as operações de atualização que são executadas a partir do com.day.compat.codeupgrade e com.adobe.cq.upgradesexecutor pacotes.

  • <cq-installation-dir>/crx-quickstart/repository

    • revision.log

      Informações sobre lançamentos de revisão.

NOTE
Os registros ImageServer e s7access não estão incluídos no Download completo pacote gerado pelo system/console/status-Bundlelist página. Para fins de suporte, em caso de problemas de Dynamic Media, anexe também os registros ImageServer e s7access ao entrar em contato com o Suporte ao cliente.

Ativando o Nível de Log DEBUG activating-the-debug-log-level

O nível de log padrão Configuração de registro do Apache Sling é Informações, portanto, as mensagens de depuração não são registradas.

Para ativar o nível de log de depuração para um Agente de log, defina a propriedade org.apache.sling.commons.log.level para depurar no repositório. Por exemplo, em /libs/sling/config/org.apache.sling.commons.log.LogManager para configurar o registro global do Apache Sling.

CAUTION
Não deixe o log no nível do log de depuração por mais tempo do que o necessário, pois ele gera muitas entradas de log, consumindo recursos.

Uma linha no arquivo de depuração geralmente começa com DEBUG, em seguida, fornece o nível de log, a ação do instalador e a mensagem de log. Por exemplo:

DEBUG 3 WebApp Panel: WebApp successfully deployed

Os níveis de log são os seguintes:

0
Erro fatal
A ação falhou e o instalador não pode continuar.
1
Erro
A ação falhou. A instalação continua, mas uma parte AEM WCM não foi instalada corretamente e não funcionará.
2
Aviso
A ação foi bem-sucedida, mas encontrou problemas. AEM WCM pode ou não funcionar corretamente.
3
Info
A ação foi bem sucedida.

Criar um arquivo de log personalizado create-a-custom-log-file

NOTE
Ao trabalhar com a Adobe Experience Manager existem vários métodos de gerenciamento das configurações desses serviços; see Configuração do OSGi para obter mais detalhes e as práticas recomendadas.

Em determinadas circunstâncias, você pode criar um arquivo de log personalizado com um nível de log diferente. Você pode fazer isso no repositório ao:

  1. Se ainda não existir, crie uma nova pasta de configuração ( sling:Folder) para o seu projeto /apps/<project-name>/config.

  2. Em /apps/<project-name>/config, crie um nó para o novo Configuração do Apache Sling Logging Logger:

    • Nome:

    org.apache.sling.commons.log.LogManager.factory.config-<identifier> (já que este é um logger)

    Onde <identifier> é substituído pelo texto livre que você (deve) inserir para identificar a instância (não é possível omitir essas informações). Por exemplo, org.apache.sling.commons.log.LogManager.factory.config-MINE

    • Tipo: sling:OsgiConfig
    note note
    NOTE
    Embora não seja um requisito técnico, é aconselhável <identifier> único.
  3. Defina as seguintes propriedades neste nó:

    • Nome: org.apache.sling.commons.log.file

      Tipo: String

      Valor: especificar o arquivo de log; por exemplo, logs/myLogFile.log

    • Nome: org.apache.sling.commons.log.names

      Tipo: String[] (String + Multi)

      Valor: especificar os serviços OSGi para os quais o agente de log deve registrar mensagens; por exemplo, todos os itens a seguir:

      • org.apache.sling
      • org.apache.felix
      • com.day
    • Nome: org.apache.sling.commons.log.level

      Tipo: String

      Valor: especifique o nível de log necessário ( debug, info, warn ou error); por exemplo debug

    • Configure os outros parâmetros conforme necessário:

      • Nome: org.apache.sling.commons.log.pattern

        Tipo: String

        Valor: especificar o padrão da mensagem de log, conforme necessário; por exemplo,

        {0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}] {3} {5}

    note note
    NOTE
    org.apache.sling.commons.log.pattern suporta até seis argumentos.
    {0} O carimbo de data e hora do tipo java.util.Date
    {1} o marcador de log
    {2} o nome do thread atual
    {3} o nome do agente de log
    {4} o nível de log
    {5} a mensagem de log
    Se a chamada de log incluir um Throwable o rastreamento de pilha é anexado à mensagem.
    note caution
    CAUTION
    org.apache.sling.commons.log.names deve ter um valor.
    note note
    NOTE
    Os caminhos do gravador de log são relativos ao crx-quickstart local.
    Portanto, um arquivo de log especificado como:
    logs/thelog.log
    escreve para:
    <cq-installation-dir>/crx-quickstart/logs/thelog.log.
    E um arquivo de log especificado como:
    ../logs/thelog.log
    grava em um diretório:
    <cq-installation-dir>/logs/
    (ou seja, próximo de <cq-installation-dir>/crx-quickstart/)
  4. Essa etapa só é necessária quando um novo Gravador é necessário (ou seja, com uma configuração diferente do Gravador padrão).

    note caution
    CAUTION
    Uma nova configuração de gravador de log é necessária somente quando o padrão existente não é adequado.
    Se nenhum Escritor explícito estiver configurado, o sistema gerará automaticamente um Escritor implícito com base no padrão.

    Em /apps/<project-name>/config, crie um nó para o novo Configuração do gravador de log do Apache Sling:

    • Nome: org.apache.sling.commons.log.LogManager.factory.writer-<identifier> (já que este é um Escritor)

      Como com o logger, <identifier> é substituído pelo texto livre que você (deve) inserir para identificar a instância (não é possível omitir essas informações). Por exemplo, org.apache.sling.commons.log.LogManager.factory.writer-MINE

    • Tipo: sling:OsgiConfig

    note note
    NOTE
    Embora não seja um requisito técnico, é aconselhável <identifier> único.

    Defina as seguintes propriedades neste nó:

    • Nome: org.apache.sling.commons.log.file

      Tipo: String

      Valor: especificar o arquivo de log de forma que ele corresponda ao arquivo especificado no logger;

      para este exemplo, ../logs/myLogFile.log.

    • Configure os outros parâmetros conforme necessário:

      • Nome: org.apache.sling.commons.log.file.number

        Tipo: Long

        Valor: especifique o número de arquivos de log que deseja manter; por exemplo, 5

      • Nome: org.apache.sling.commons.log.file.size

        Tipo: String

        Valor: Especificar como necessário para controlar a rotação dos ficheiros por tamanho/data; por exemplo, '.'yyyy-MM-dd

    note note
    NOTE
    org.apache.sling.commons.log.file.size controla a rotação do arquivo de log definindo:
    • um tamanho máximo de arquivo
    • um cronograma de data/hora
    para indicar quando um novo arquivo será criado (e o arquivo existente será renomeado de acordo com o padrão de nome).
    • É possível especificar um limite de tamanho com um número. Se nenhum indicador de tamanho for fornecido, isso será considerado o número de bytes ou você poderá adicionar um dos indicadores de tamanho - KB, MBou GB (caso é ignorado).
    • Um cronograma de hora/data pode ser especificado como java.util.SimpleDateFormat padrão. Isso define o período após o qual o arquivo será girado; também o sufixo anexado ao arquivo girado (para identificação).
    O padrão é '.'aaaa-MM-dd (para rotação diária do log).
    Por exemplo, à meia-noite de 20 de janeiro de 2010 (ou quando a primeira mensagem de log após isso ocorrer para ser precisa), …/logs/error.log será renomeado para …/logs/error.log.2010-01-20. O registro para o dia 21 de janeiro será feito para (um novo e vazio) …/logs/error.log até ser acumulado na próxima mudança de dia.
    table 0-row-2 1-row-2 2-row-2 3-row-2 4-row-2 5-row-2
    '.'yyyy-MM Rotação no início de cada mês
    '.'yyyy-ww Rotação no primeiro dia de cada semana (depende da localidade).
    '.'yyyy-MM-dd Rotação à meia-noite todos os dias.
    '.'yyyy-MM-dd-a Rotação à meia-noite e ao meio-dia de cada dia.
    '.'yyyy-MM-dd-HH Rotação no topo de cada hora.
    '.'yyyy-MM-dd-HH-mm Rotação no início de cada minuto.
    Observação: Ao especificar uma hora/data:
    1. O texto literal "escape" deve estar dentro de um par de aspas simples (' ');

      isso evita que determinados caracteres sejam interpretados como letras padrão.

    2. Use somente caracteres permitidos para um nome de arquivo válido em qualquer lugar na opção .

  5. Leia seu novo arquivo de log com a ferramenta escolhida.

    O arquivo de log criado por este exemplo será ../crx-quickstart/logs/myLogFile.log.

O Felix Console também fornece informações sobre o suporte ao Sling Log em ../system/console/slinglog; por exemplo http://localhost:4502/system/console/slinglog.

Encontrar os registros de auditoria finding-the-audit-records

São mantidos registros de auditoria para fornecer um registro de quem fez o quê e quando. Registros de auditoria diferentes são gerados para eventos AEM WCM e OSGi.

AEM registros de Auditoria WCM mostrados durante a Criação de página aem-wcm-audit-records-shown-when-page-authoring

  1. Abra uma página.

  2. No sidekick, você pode selecionar a guia com o ícone de cadeado e, em seguida, clicar duas vezes em Log de Auditoria…

  3. Uma nova janela abrirá mostrando a lista de registros de auditoria da página atual.

    screen_shot_2012-02-02at43601pm

  4. Clique em OK quando quiser fechar a janela.

AEM registros de Auditoria do WCM no repositório aem-wcm-auditing-records-within-the-repository

No /var/audit , os registros de auditoria são mantidos de acordo com o recurso. É possível fazer o detalhamento até visualizar os registros individuais e as informações que eles contêm.

Essas entradas têm as mesmas informações que são exibidas ao editar uma página.

Registros de Auditoria do OSGi no Console da Web osgi-audit-records-from-the-web-console

Os eventos OSGi também geram registros de auditoria que podem ser vistos a partir do Status da configuração guia -> Arquivos de registro no Console da Web AEM:

screen_shot_2012-02-13at50346pm

Monitorar seus agentes de replicação monitoring-your-replication-agents

Você pode monitorar seu filas de replicação para detectar quando uma fila está inativa ou bloqueada - o que pode indicar um problema com uma instância de publicação ou sistema externo:

  • todas as filas necessárias estão ativadas?

  • ainda são necessárias filas desativadas?

  • all enabled as filas devem ter o status idle ou active, que indicam um funcionamento normal; nenhuma fila deve ser blocked, que é frequentemente um sinal de problemas no lado dos receptores.

  • se o tamanho da fila aumentar com o tempo, isso pode indicar uma fila bloqueada.

Para monitorar um agente de replicação:

  1. Acesse o Ferramentas em AEM.

  2. Clique em Replicação.

  3. Clique duas vezes no link para agentes do ambiente apropriado (no painel esquerdo ou direito); por exemplo Agentes do autor.

    A janela resultante mostra uma visão geral de todos os agentes de replicação para o ambiente do autor, incluindo o target e o status.

  4. Clique no nome do agente apropriado (que é um link) para mostrar informações detalhadas sobre esse agente:

    chlimage_1-8

    Aqui você pode:

    • Veja se o agente está ativado.
    • Consulte o target de qualquer replicação.
    • Veja se a fila de replicação está ativa no momento (habilitada).
    • Veja se há algum item na fila.
    • Atualizar ou Limpar para atualizar a exibição de entradas da fila; isso ajuda você a ver os itens entrando e deixando a fila.
    • Exibir registro para acessar o log de quaisquer ações pelo agente de replicação.
    • Testar conexão para a instância do target.
    • Forçar nova tentativa em qualquer item da fila, se necessário.
    note caution
    CAUTION
    Não use o link "Testar conexão" para a Caixa de saída de replicação inversa em uma instância de publicação.
    Se um teste de replicação for executado para uma fila da Caixa de saída, todos os itens mais antigos que a replicação de teste serão reprocessados com cada replicação inversa.
    Se esses itens já existirem em uma fila, eles poderão ser encontrados com a seguinte consulta XPath JCR e deverão ser removidos.
    /jcr:root/var/replication/outbox//*[@cq:repActionType='TEST']

Novamente, você pode desenvolver uma solução para detectar todos os agentes de replicação (localizados em /etc/replication/author ou /etc/replication/publish), em seguida, verifique o status do agente ( enabled, disabled) e a fila subjacente ( active, idle, blocked).

Monitorar desempenho monitoring-performance

Otimização de desempenho é um processo interativo que recebe foco durante o desenvolvimento. Após a implantação, geralmente é revisado após intervalos ou eventos específicos.

Os métodos usados ao coletar informações para otimização também podem ser usados para monitoramento contínuo.

NOTE
Específico configurações disponíveis para melhorar o desempenho também pode ser verificado.

Apresenta-se a seguir uma lista de problemas comuns de desempenho que ocorrem, juntamente com propostas sobre como detectar e contrariá-los.

Área
Sintoma(s)
Para aumentar a capacidade…
Para reduzir o volume…
Client
Alto uso da CPU do cliente.
Instale uma CPU cliente com desempenho mais alto.
Simplifique o layout (HTML).
Baixo uso da CPU do servidor.
Atualize para um navegador mais rápido.
Melhore o cache do lado do cliente.
Alguns clientes são rápidos, alguns lentos.
Servidor
Rede
O uso da CPU é baixo em servidores e clientes.
Remova qualquer gargalo de rede.
Melhore/otimize a configuração do cache do cliente.
A navegação local no servidor é (comparativamente) rápida.
Aumente a largura de banda da rede.
Reduza o "peso" das páginas da Web (por exemplo, menos imagens, HTML otimizado).
Web-server
O uso da CPU no servidor da Web é alto.
Cluster seus servidores da Web.
Reduza as ocorrências por página (visita).
Use um balanceador de carga de hardware.
Aplicativo
O uso da CPU do servidor é alto.
Cluster as instâncias de AEM.
Procure e elimine pernos de CPU e memória (use análise de código, saída de tempo etc.).
Alto consumo de memória.
Melhore o armazenamento em cache em todos os níveis.
Tempos de resposta baixos.
Otimizar modelos e componentes (por exemplo, estrutura, lógica).
Repositório
Cache

Problemas de desempenho podem resultar de várias causas que não têm nada a ver com seu site, incluindo lentidão temporária na velocidade da conexão, carga da CPU e muito mais.

Também pode afetar todos os seus visitantes ou apenas um subconjunto deles.

Todas essas informações precisam ser obtidas, classificadas e analisadas antes que você possa otimizar o desempenho geral ou resolver problemas específicos.

  • Antes de enfrentar um problema de desempenho:

    • recolher o máximo possível de informações para desenvolver um bom conhecimento do sistema em circunstâncias normais
  • Quando você tiver um problema de desempenho:

    • tente replicá-lo com um (ou preferencialmente mais) navegador padrão da Web, em um cliente diferente que você sabe que tem bom desempenho geral e/ou no próprio servidor (se possível)

    • verifique se algo (relacionado ao sistema) foi alterado em um espaço de tempo apropriado e se alguma dessas alterações pode ter afetado o desempenho

    • faça perguntas como:

      • o problema ocorre apenas em momentos específicos?
      • o problema ocorre apenas em páginas específicas?
      • outras solicitações são afetadas?
    • colete o máximo possível de informações para comparar com seu conhecimento do sistema em circunstâncias normais:

Ferramentas para monitorar e analisar o desempenho tools-for-monitoring-and-analyzing-performance

A seguir, há uma breve visão geral de algumas das ferramentas disponíveis para monitorar e analisar o desempenho.

Alguns deles dependerão do seu sistema operacional.

Ferramenta
Usado para analisar...
Uso / Mais informações...
request.log
Tempos de resposta e simultaneidade.
Interpretação do request.log.
truss/strace
Carregamentos de página

Comandos Unix/Linux para rastrear chamadas e sinais do sistema. Aumente o nível de log para INFO.

Analise o número de carregamentos de página por solicitação, quais páginas etc.

Despejos de thread
Observe threads da JVM. Identifique as disputas, bloqueios e corredores longos.

Dependendo do sistema operacional:
- Unix/Linux: kill -QUIT <pid>
- Windows (modo console): Ctrl-Break

Ferramentas de análise também estão disponíveis, como TDA.

Despejos de heap
Problemas de memória insuficiente que causam desempenho lento.

Adicione:
-XX:+HeapDumpOnOutOfMemoryError
para a chamada java para AEM.

Consulte a Guia de solução de problemas para Java SE 6 com HotSpot VM.

Chamadas do sistema
Identificar problemas de tempo.

Chamadas para System.currentTimeMillis() ou com.day.util.Timing são usados para gerar carimbos de data e hora do código ou por meio de HTML-comments.

Observação: Devem ser implementadas de modo a poderem ser ativadas/desativadas, conforme necessário; quando um sistema está a funcionar sem problemas, não será necessário o custo indireto da recolha de estatísticas.

Apache Bench
Identifique vazamentos de memória, analise seletivamente o tempo de resposta.

o uso básico é:

ab -k -n <requests> -c <concurrency> <url>

Consulte Apache Bench e página do homem ab para obter detalhes completos.

Análise de pesquisa
Executar consultas de pesquisa offline, identificar o tempo de resposta da consulta, testar e confirmar o conjunto de resultados.
JMeter
Ensaios de carga e de funcionamento.
https://jakarta.apache.org/jmeter/
JProfiler
Criação de perfis de CPU e memória detalhados.
https://www.ej-technologies.com/
JConsole
Observe métricas e threads da JVM.

Uso: jconsole

Consulte jconsole e Monitorar o desempenho usando o JConsole.

Observação: Com o JDK 1.6, o JConsole é extensível com plug-ins; por exemplo, Top ou TDA (Thread Dump Analyzer).

Java VisualVM
Observe métricas, threads, memória e criação de perfis da JVM.

Uso: jvisual ou visual

Consulte jvisualvm, visual e Monitorar o desempenho usando o (J)VisualVM.

Observação: Com o JDK 1.6, o VisualVM é extensível com plug-ins.

truss/strace, lsof
Chamada de kernel detalhada e análise de processo (Unix).
Comandos Unix/Linux.
Estatísticas de tempo
Consulte estatísticas de tempo para renderização da página.
Para ver as estatísticas de tempo da renderização da página, você pode usar Ctrl-Shift-U juntamente com ?debugClientLibs=true definido no URL.
Ferramenta de criação de perfis de CPU e memória
Usado ao analisar solicitações lentas durante o desenvolvimento.
Por exemplo, YourKit.
Coleta de informações
O estado contínuo da instalação.
Saber o máximo possível sobre sua instalação também pode ajudá-lo a rastrear o que pode ter causado uma mudança no desempenho e se essas alterações são justificadas. Essas métricas precisam ser coletadas em intervalos regulares para que você possa ver facilmente alterações significativas.

Interpretação do request.log interpreting-the-request-log

Esse arquivo registra as informações básicas sobre cada solicitação feita ao AEM. A partir destas valiosas conclusões, podemos extrair.

O request.log O oferece uma maneira integrada de obter uma visão de quanto tempo as solicitações levam. Para fins de desenvolvimento, é útil tail -f o request.log e observe os tempos de resposta lentos. Para analisar um request.log recomendamos que utilização de rlog.jar o que permite classificar e filtrar por tempos de resposta.

Recomendamos isolar as páginas "lentas" do request.log, em seguida, ajustá-las individualmente para um melhor desempenho. Isso geralmente é feito incluindo métricas de desempenho por componente ou usando uma ferramenta de definição de perfil de desempenho, como [yourkit](https://www.yourkit.com/).

Monitorar o tráfego no seu site monitoring-traffic-on-your-website

O log de solicitações registra cada solicitação feita, juntamente com a resposta feita:

09:43:41 [66] -> GET /author/y.html HTTP/1.1
09:43:41 [66] <- 200 text/html 797ms

Ao totalizar todas as entradas de GET em um período específico (por exemplo, durante vários períodos de 24 horas), você pode fazer declarações sobre o tráfego médio em seu site.

Monitoramento dos tempos de resposta com o request.log monitoring-response-times-with-the-request-log

Um bom ponto de partida para análise de desempenho é o log de solicitação:

<cq-installation-dir>/crx-quickstart/logs/request.log

O log tem a seguinte aparência (as linhas são encurtadas para simplificar):

31/Mar/2009:11:32:57 +0200 [379] -> GET /path/x HTTP/1.1
31/Mar/2009:11:32:57 +0200 [379] <- 200 text/html 33ms
31/Mar/2009:11:33:17 +0200 [380] -> GET /path/y HTTP/1.1
31/Mar/2009:11:33:17 +0200 [380] <- 200 application/json 39ms

Esse log tem uma linha por solicitação ou resposta:

  • A data em que cada pedido ou resposta foi apresentado.

  • O número da solicitação, entre colchetes. Esse número corresponde à solicitação e à resposta.

  • Uma seta indicando se esta é uma solicitação (seta apontando para a direita) ou uma resposta (seta para a esquerda).

  • Para solicitações, a linha contém:

    • o método (tipicamente, GET, HEAD ou POST)
    • a página solicitada
    • o protocolo
  • Para respostas, a linha contém:

    • o código de status (200 significa "sucesso", 404 significa "página não encontrada"
    • o tipo MIME
    • o tempo de resposta

Usando pequenos scripts, você pode extrair as informações necessárias do arquivo de log e reunir as estatísticas desejadas. A partir dessas páginas, você pode ver quais páginas ou tipos de páginas estão lentas e se o desempenho geral é satisfatório.

Monitorar os tempos de resposta da pesquisa com o request.log monitoring-search-response-times-with-the-request-log

As solicitações de pesquisa também são registradas no arquivo de log:

31/Mar/2009:11:35:34 +0200 [338] -> GET /author/playground/en/tools/search.html?query=dilbert&size=5&dispenc=utf-8 HTTP/1.1
31/Mar/2009:11:35:34 +0200 [338] <- 200 text/html 1562ms

Assim, como acima, você pode usar scripts para extrair as informações relevantes e criar estatísticas.

No entanto, após determinar o tempo de resposta, talvez seja necessário analisar por que a solicitação está levando tempo e o que pode ser feito para melhorar a resposta.

Monitoramento do número e impacto de usuários simultâneos monitoring-the-number-and-impact-of-concurrent-users

Novamente, a variável request.log pode ser usada para monitorar a simultaneidade e a reação do sistema a ela.

Devem ser feitos testes para determinar quantos usuários simultâneos o sistema pode lidar antes que um impacto negativo seja observado. Mais uma vez, os scripts podem ser usados para extrair resultados do arquivo de log:

  • monitorar o número de solicitações feitas em um período específico, por exemplo, um minuto
  • Testar simultaneamente os efeitos de um número específico de utilizadores que formulam os mesmos pedidos (o mais próximo possível); Por exemplo, 30 usuários clicando em Salvar ao mesmo tempo.
31/Mar/2009:11:45:29 +0200 [333] -> GET /author/libs/Personalize/content/statics.close.gif HTTP/1.1
31/Mar/2009:11:45:29 +0200 [334] -> GET /author/libs/Personalize/content/statics.detach.gif HTTP/1.1
31/Mar/2009:11:45:30 +0200 [335] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTpCxyuBNiTCoiBMmw000.default.gif HTTP/1.1
31/Mar/2009:11:45:32 +0200 [335] <- 304 text/html 0ms
31/Mar/2009:11:45:33 +0200 [334] <- 200 image/gif 31ms
31/Mar/2009:11:45:38 +0200 [333] <- 200 image/gif 31ms
31/Mar/2009:11:45:42 +0200 [336] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTZRXunQbbQtvuuCMbRRBuWXz0000.default.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [337] -> GET /author/titlebar_bg.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [336] <- 304 text/html 0ms
31/Mar/2009:11:45:44 +0200 [337] <- 304 text/html 0ms

Usar o rlog.jar para localizar solicitações com tempos de longa duração using-rlog-jar-to-find-requests-with-long-duration-times

AEM inclui várias ferramentas auxiliares localizadas em:
<cq-installation-dir>/crx-quickstart/opt/helpers

Um deles, rlog.jar, pode ser usada para classificar rapidamente request.log para que as solicitações sejam exibidas por duração, do tempo mais longo ao mais curto.

O comando a seguir mostra os possíveis argumentos:

$java -jar rlog.jar
Request Log Analyzer Version 21584 Copyright 2005 Day Management AG
Usage:
  java -jar rlog.jar [options] <filename>
Options:
  -h               Prints this usage.
  -n <maxResults>  Limits output to <maxResults> lines.
  -m <maxRequests> Limits input to <maxRequest> requests.
  -xdev            Exclude POST request to CRXDE.

Por exemplo, você pode executá-lo especificando request.log como parâmetro e mostra as 10 primeiras solicitações que têm a maior duração:

$ java -jar ../opt/helpers/rlog.jar -n 10 request.log
*Info * Parsed 464 requests.
*Info * Time for parsing: 22ms
*Info * Time for sorting: 2ms
*Info * Total Memory: 1mb
*Info * Free Memory: 1mb
*Info * Used Memory: 0mb
------------------------------------------------------
     18051ms 31/Mar/2009:11:15:34 +0200 200 GET /content/geometrixx/en/company.html text/ html
      2198ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/cq/widgets.js application/x-javascript
      1981ms 31/Mar/2009:11:15:11 +0200 200 GET /libs/wcm/content/welcome.html text/html
      1973ms 31/Mar/2009:11:15:52 +0200 200 GET /content/campaigns/geometrixx.teasers..html text/html
      1883ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/security/cq-security.js application/x-javascript
      1876ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets.js application/x-javascript
      1869ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets/themes/default.js application/x-javascript
      1729ms 30/Mar/2009:16:45:56 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8
      1510ms 31/Mar/2009:11:15:34 +0200 200 GET /bin/wcm/contentfinder/asset/view.json/ content/dam?_dc=1238490934657&query=&mimeType=image&_charset_=utf-8 application/json
      1462ms 30/Mar/2009:17:23:08 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8

Pode ser necessário concatenar o indivíduo request.log arquivos se precisar fazer essa operação em uma amostra de dados grande.

Apache Bench apache-bench

Para minimizar o impacto de casos especiais (como coleta de lixo, etc.), é recomendável usar uma ferramenta como apachebench (consulte por exemplo, ab para obter mais documentação) para ajudar a identificar vazamentos de memória e analisar seletivamente o tempo de resposta.

O Apache Bench pode ser usado da seguinte maneira:

$ ab -c 5 -k -n 1000 "http://localhost:4503/content/geometrixx/en/company.html"
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, https://www.zeustech.net/
Licensed to The Apache Software Foundation, https://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software: Day-Servlet-Engine/4.1.52
Server Hostname: localhost
Server Port: 4503

Document Path: /content/geometrixx/en/company.html
Document Length: 24127 bytes

Concurrency Level: 5
Time taken for tests: 69.766 seconds
Complete requests: 1000
Failed requests: 998
(Connect: 0, Receive: 0, Length: 998, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 24160923 bytes
HTML transferred: 24010923 bytes
Requests per second: 14.33 /sec (mean)
Time per request: 348.828 [ms] (mean)
Time per request: 69.766 [ms] (mean, across all concurrent requests)
Transfer rate: 338.20 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.9 0 58
Processing: 138 347 568.5 282 8106
Waiting: 137 344 568.1 281 8106
Total: 139 348 568.4 283 8106

Percentage of the requests served within a certain time (ms)
50% 283
66% 323
75% 356
80% 374
90% 439
95% 512
98% 1047
99% 1132
100% 8106 (longest request)

Os números acima são obtidos de um notebook MAcBook Pro padrão (meados de 2010) acessando a página da empresa geometrixx, conforme incluído em uma instalação padrão do AEM. A página é muito simples, mas não é otimizada para desempenho.

apachebench também exibe o tempo por solicitação como a média, em todas as solicitações simultâneas; see Time per request: 54.595 [ms] (média, em todas as solicitações simultâneas). Você pode alterar o valor do parâmetro de simultaneidade -c (número de solicitações múltiplas a serem executadas de cada vez) para ver quaisquer efeitos.

Contadores de solicitações request-counters

As informações sobre o tráfego de solicitação (número de solicitações durante um período de tempo específico) fornecem uma indicação da carga em sua instância. Essas informações podem ser extraídas de request.log, embora o uso de contadores automatize a coleta de dados para permitir que você veja:

  • diferenças significativas na atividade (ou seja, diferença entre "muitos pedidos" e "baixa atividade")
  • quando uma instância não está sendo usada
  • qualquer reinicialização (contadores são redefinidos como 0)

Para automatizar a coleta de informações, você também pode instalar um RequestFilter para incrementar um contador em cada solicitação. Vários contadores podem ser usados para períodos diferentes.

As informações recolhidas podem ser utilizadas para indicar:

  • alterações significativas na atividade
  • uma instância redundante
  • qualquer reinicialização (contador redefinido para 0)

Comentários de HTML html-comments

Recomenda-se que cada projeto inclua html comments para desempenho do servidor. É possível encontrar muitos bons exemplos públicos; selecione uma página, abra a fonte da página para visualizar e role até o final, código como o seguinte pode ser visto:

</body>
 </html>
        <!--
        Page took 58 milliseconds to be rendered by server
         -->

Monitorar o desempenho usando o JConsole monitoring-performance-using-jconsole

O comando ferramenta jconsole O está disponível com o JDK.

  1. Inicie a instância do AEM.

  2. Executar jconsole.

  3. Selecione a instância do AEM e Connect.

  4. No Local aplicativo, clique duas vezes com.day.crx.quickstart.Main; a Visão geral será exibida como padrão:

    chlimage_1-87

    Depois disso, você poderá selecionar outras opções.

Monitorar o desempenho usando o (J)VisualVM monitoring-performance-using-j-visualvm

Desde o JDK 1.6, o comando da ferramenta jvisualvm está disponível. Depois de instalar o JDK 1.6, você pode:

  1. Inicie a instância do AEM.

    note note
    NOTE
    Se estiver usando o Java 5, você pode adicionar o -Dcom.sun.management.jmxremote argumento para a linha de comando java que inicia a JVM. O JMX é ativado por padrão com o Java 6.
  2. Execute:

    • jvisualvm: na pasta bin do JDK 1.6 (versão testada)
    • visualvm: pode ser baixado de VisualVM (versão de borda hemorrágica)
  3. No Local aplicativo, clique duas vezes com.day.crx.quickstart.Main; a Visão geral será exibida como padrão:

    chlimage_1-88

    Depois disso, você pode selecionar outras opções, incluindo Monitor:

    chlimage_1-89

Você pode usar essa ferramenta para gerar despejos de encadeamento e despejos de cabeçote de memória. Estas informações são frequentemente solicitadas pela equipe de suporte técnico.

Coleta de informações information-collection

Saber o máximo possível sobre sua instalação pode ajudá-lo a rastrear o que pode ter causado uma mudança de desempenho e se essas alterações são justificadas. Essas métricas precisam ser coletadas em intervalos regulares para que você possa ver facilmente alterações significativas.

As seguintes informações podem ser úteis:

Quantos autores estão trabalhando com o sistema? how-many-authors-are-working-with-the-system

Para ver o número de autores que usaram o sistema desde a instalação, use a linha de comando:

cd <cq-installation-dir>/crx-quickstart/logs
cut -d " " -f 3 access.log | sort -u | wc -l

Para ver o número de autores trabalhando em uma determinada data:

grep "<date>" access.log | cut -d " " -f 3 | sort -u | wc -l

Qual é o número médio de ativações de página por dia? what-is-the-average-number-of-page-activations-per-day

Para ver o número total de ativações de página desde que a instalação do servidor use uma consulta de repositório; via CRXDE - Ferramentas - Consulta:

  • Tipo XPath

  • Caminho /

  • Consulta //element(*, cq:AuditEvent)[@cq:type='Activate']

Em seguida, calcule o número de dias decorridos desde a instalação para calcular a média.

Quantas páginas você mantém atualmente neste sistema? how-many-pages-do-you-currently-maintain-on-this-system

Para ver o número de páginas atualmente no servidor, use uma consulta de repositório; via CRXDE - Ferramentas - Consulta:

  • Tipo XPath

  • Caminho /

  • Consulta //element(*, cq:Page)

Se você usa o MSM, qual é o número médio de implantações por mês? if-you-use-msm-what-is-the-average-number-of-rollouts-per-month

Para determinar o número total de implantações desde a instalação, use uma consulta de repositório; via CRXDE - Ferramentas - Consulta:

  • Tipo XPath

  • Caminho /

  • Consulta //element(*, cq:AuditEvent)[@cq:type='PageRolledOut']

Calcule o número de meses decorridos desde a instalação para calcular a média.

Qual é o número médio de Live Copies por mês? what-is-the-average-number-of-live-copies-per-month

Para determinar o número total de Live Copies feitas desde a instalação, use uma consulta de repositório; via CRXDE - Ferramentas - Consulta:

  • Tipo XPath

  • Caminho /

  • Consulta //element(*, cq:LiveSyncConfig)

Use novamente o número de meses decorridos desde a instalação para calcular a média.

Se você usa o AEM Assets, quantos ativos você mantém atualmente no Assets? if-you-use-aem-assets-how-many-assets-do-you-currently-maintain-in-assets

Para ver quantos ativos do DAM você mantém atualmente, use uma consulta de repositório; via CRXDE - Ferramentas - Consulta:

  • Tipo XPath

  • Caminho /

  • Consulta /jcr:root/content/dam//element(*, dam:Asset)

Qual é o tamanho médio dos ativos? what-is-the-average-size-of-the-assets

Para determinar o tamanho total da variável /var/dam pasta:

  1. Use o WebDAV para mapear o repositório para o sistema de arquivos local.

  2. Use a linha de comando:

    code language-shell
    cd /Volumes/localhost/var
    du -sh dam/
    

    Para obter o tamanho médio, divida o tamanho global pelo número total de ativos em /var/dam (acima).

Quantos modelos são usados atualmente? how-many-templates-are-currently-used

Para ver o número de modelos atualmente no servidor, use uma consulta de repositório; via CRXDE - Ferramentas - Consulta:

  • Tipo XPath

  • Caminho /

  • Consulta //element(*, cq:Template)

Quantos componentes são usados atualmente? how-many-components-are-currently-used

Para ver o número de componentes atualmente no servidor, use uma consulta de repositório; via CRXDE - Ferramentas - Consulta:

  • Tipo XPath

  • Caminho /

  • Consulta //element(*, cq:Component)

Quantas solicitações por hora você tem no sistema de criação em horário de pico? how-many-requests-per-hour-do-you-have-on-the-author-system-at-peak-time

Para determinar as solicitações por hora que você tem no sistema de criação no horário de pico:

  1. Para determinar o número total de solicitações desde a instalação, use a linha de comando:

    code language-shell
    cd <cq-installation-dir>/crx-quickstart/logs
    grep -R "\->" request.log | wc -l
    
  2. Para determinar as datas de início e término:

    code language-shell
    vim request.log
    G / 1G: for the last/first lines
    

    Use esses valores para calcular o número de horas decorridas desde a instalação e, em seguida, o número médio de solicitações por hora.

Quantas solicitações por hora você tem no sistema de publicação no horário de pico? how-many-requests-per-hour-do-you-have-on-the-publish-system-at-peak-time

Repita o procedimento acima na sua instância de publicação.

Análise de cenários específicos analyzing-specific-scenarios

Veja a seguir uma lista de sugestões sobre o que verificar se você começa a enfrentar determinados problemas de desempenho. A lista não é (infelizmente) totalmente abrangente.

CPU em 100% cpu-at

Se a CPU do seu sistema estiver constantemente em execução a 100%, consulte:

Sem memória out-of-memory

Embora tais erros devam ser detectados durante o Desenvolvimento e o Teste, alguns cenários podem escapar.

Se o sistema estiver ficando sem memória, isso pode ser visto de várias maneiras, incluindo degradação de desempenho e mensagens de erro, incluindo o subtexto:

java.lang.OutOfMemoryError

Nesses casos, verifique:

E/S de disco disk-i-o

Se o sistema estiver ficando sem espaço em disco ou se você perceber que o disco está quebrando, veja:

Degradação regular do desempenho regular-performance-degradation

Se o desempenho da sua instância se deteriorar após cada reinicialização (às vezes uma semana ou mais tarde), o seguinte poderá ser verificado:

Ajuste da JVM jvm-tuning

A Java Virtual Machine (JVM) melhorou significativamente em relação ao ajuste (especialmente desde o Java 7). Por causa disso, especificar um tamanho razoável fixo da JVM e usar os padrões geralmente será adequado.

Se as configurações padrão não forem adequadas, é importante estabelecer um método para monitorar e avaliar o desempenho do GC antes de tentar ajustar a JVM; isso pode envolver fatores de monitoramento, incluindo tamanho do heap, algoritmo e outros aspectos.

Algumas opções comuns são:

  • VerboseGC:

    code language-none
    -verbose:gc \
     -Xloggc:$LOGS/verbosegc.log \
     -XX:+PrintGCDetails \
     -XX:+PrintGCDateStamps
    

O log resultante pode ser assimilado por um visualizador de GC, como:

[https://www.ibm.com/developerworks/library/j-ibmtools2/](https://www.ibm.com/developerworks/library/j-ibmtools2/)

Ou JConsole:

  • Essas configurações são para uma conexão JMX "aberta":

    code language-none
    -Dcom.sun.management.jmxremote \
     -Dcom.sun.management.jmxremote.port=8889 \
     -Dcom.sun.management.jmxremote.authenticate=false \
     -Dcom.sun.management.jmxremote.ssl=false
    
  • Em seguida, conecte-se à JVM com o JConsole; consulte:
    [https://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html](https://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html)

Isso ajudará você a ver a quantidade de memória sendo usada, quais algoritmos GC estão sendo usados, quanto tempo levam para serem executados e qual efeito isso tem no desempenho do aplicativo. Sem isso, o ajuste é apenas "botões de giro aleatório".

NOTE
Para a VM do Oracle, há também informações em:
https://docs.oracle.com/javase/7/docs/technotes/guides/vm/server-class.html
recommendation-more-help
6a71a83d-c2e0-4ce7-a6aa-899aa3885b56