Runtime
Como monitorar a performance das aplicações Telescope/Eligo?
RT.FAQ-8233
Este procedimento que deve ser executado para tentar identificar a causa de problemas de performance.
Memória, queries e locks
Acesse os dados de monitoramento através de URL
http://..../ELIGO/ctr/Notification/info
Veja como os itens:
- DATABASE_LOCKS - A existência de locks demorados causa muitos problemas de performance. Isso explica determinadas requisições "trancarem".
- DATABASE_QUERIES - A existência de queries demorados causa muitos problemas de performance.
- MEMORY_HEAP - A HEAP é muito dinamica (sobe e desce). Pode ter picos perto de 100% sem problemas, mas deve-se acompanha-la por algum tempo. Se ela nunca baixar de 70%, pode identificar um problema relacionado ao uso excessivo de memória.
- MEMORY_CMS_OLD_GEN - Tende a ser o patamar "baixo" da heap. Se o valor da OLD estiver próximo do valor máximo da heap, significa um problema relacionado ao uso excessivo de memória.
- MEMORY_CMS_PERM_GEN - Está relacionado à carga de classes do sistema. Pode ficar alto após atualizações do sistema. Não causa problemas de performance mas se ficar muito alto pode causar a parada do sistema.
Se valor de OLD estiver alto, recomenda-se uma análise dos objetos em memória através de um dump da heap: Como obter e analisar o consumo de memória em aplicações Java?
Sessões correntes
Também é possivel verificar o que cada usuário está executando em um dado instante.
Para isso, acesse a tela
LstSessions
Logs da aplicação
O monitoramento pode ser feito através da consulta aos logs do sistema. Em primeira instância, as queries SQL abaixo irão dar uma visão geral do comportamento da aplicação nos últimos 30 minutos.
Se quiser aumentar este período, basta alterar a expressão do primeiro comando "select".
select '30 minute' as tx;
let p=last;
select count(1) as Requisicoes
, round(avg(tempo)) as "Tempo médio (ms)"
, sum(tempo) as "Tempo total"
, round(sum(tempo)/extract(epoch FROM (interval '${p.tx}'))/10) as "% Tempo"
, round(count(1)/30) as "Requisições/min"
, count(distinct sessao_id) as "Sessões"
, count(distinct usuario) as "Usuários"
from logs
where data_hora > (current_timestamp - interval '${p.tx}')
and tipo='REQUEST';
select ct as "Tempo da requisição", count(1), count(1)*100/${last.requisicoes} as "%"
from (
select case
when tempo <= 100 then '0) 0 - 100ms'
when tempo > 100 and tempo <= 500 then '1) 100ms - 500ms'
when tempo > 500 and tempo <= 1000 then '2) 500ms - 1s'
when tempo > 1000 and tempo <= 5000 then '3) 1s - 5s'
else '4) > 5s' end as ct
from logs
where data_hora > (current_timestamp - interval '${p.tx}')
and tipo='REQUEST'
) q
group by ct
order by ct;
select origem as "Tela de origem"
, count(1) as "Requisições"
, round(avg(tempo)) as "Tempo médio (ms)"
, min(tempo), max(tempo)
, sum(tempo) as "Custo total (ms)"
from logs
where data_hora > (current_timestamp - interval '${p.tx}')
and tipo = 'REQUEST'
group by tipo, origem
order by avg(tempo) desc;
select origem as "Tela de origem"
, count(1) as "Requisições"
, round(avg(tempo)) as "Tempo médio (ms)"
, min(tempo), max(tempo)
, sum(tempo) as "Custo total (ms)"
from logs
where data_hora > (current_timestamp - interval '${p.tx}')
and tipo = 'REQUEST'
group by tipo, origem
order by sum(tempo) desc;
A primeira parte dá um resumo dos últimos 30 minutos de uso do sistema.
A segunda parte, tabula as requisições conforme o tempo de execução. Espera-se que o maior número de requisições se concentre nas faixas mais rápidas de execução.
A terceira e quarta partes, apresenta as telas que estão tem a média mais alta e que estão sendo mais "caras" para o sistema em termos de performance.
Observações
- Estas queries apenas demonstram como está a performance do sistema com relação à requisições executadas. Elas não indicam a causa e requisições que ainda estão em execução não são contabilizadas.
- Em alguns casos, tempos elevados não oferecem impacto de performance no resto do sistema e são causados por dependências externas, tais como o envio de e-mail, comunicação com um web-service, etc.
Uso de CPU no servidor
Verificar como está o uso da CPU no servidor.
Em caso de Linux, é necessário ter acesso SSH ao servidor e executar o comando:
top
Em caso de Windows, pela aba "Processos" do Gerenciador de Tarefas (ordenar por CPU decrescente).
Número de requisições chegando ao servidor
No servidor, execute o comando abaixo. Este comando apresenta o número de requisições que o tomcat está respondendo a cada minuto.
grep "`date +%d/%b/%Y`" localhost_access_log.2014-03-18.txt|cut -d"[" -f2|cut -d":" -f1-3|uniq -c