Administração do sistema
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 (sistema lento).
De uma forma geral, podemos dividir problemas de performance identificando os seguintes elementos:
- CPU - Existe algum processo que utiliza a CPU do sistema de forma intensiva, causando lentidão nos demais processos.
- IO - Existe um ou mais processos exigindo muita acesso ao HD, tornando lento qualquer acesso ao mesmo.
- Rede - A comunicação com o servidor está lenta. O processamento em si está OK, porém o tráfego dos resultados até navegador do cliente é demorado.
- Locks de banco - Algum processo bloqueou registros do banco de dados em uma transação que ainda não foi encerrada e que bloqueia o acesso total ou parcial às respectivas tabelas fazendo com que outros processos fiquem aguardando o encerramento da primeira.
- Locks de memória - Semelhante aos locks de banco mas com objetos compartilhados na memória do sistema.
Ferramentas
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).
Uso de IO no servidor
No caso de Linuxo, usar
iotop
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
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
LstThreads
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.
Dump jstack
Quando o servidor não está respondendo mas o tomcat está rodando, então será necessário capturar informações da VM da seguinte forma:
Verificar onde o jstack está instalado:
find /usr/lib/jvm -name jstack
Deve retornar algo como:
/usr/lib/jvm/java-7-oracle/bin/jstack
Se não retornar, será necessário instalar alguma JDK (mesmo que ela não seja utilizada pelo Tomcat).
Após ter o caminho de execução do jstack, será necessário descobrir o PID do Tomcat que está sendo executado.
ps aux|grep tomcat
Executar o jstack conforme o caminho descoberto antes e o número do processo do tomcat
/usr/lib/jvm/java-7-oracle/bin/jstack -F {pid do tomcat} > threads.txt
Depois disso, o arquivo threads.txt conterá um dump de todas as threads que estão em execução e que pode ser utilizado para análise do problema.
A opção "-l" pode ser adicionada caso seja necessário obter mais detalhes.
Ver também: