Quando o vilão está fora do banco…

Analisando outro vilão…Bom dia gente! Véspera de feriadão de Páscoa, na espera dos chocolates do coelho… hehehe. Do jeito que a coisa está este ano o coelho este ano vai ser magrinho né??
Bem, eu, como estou precisando emagrecer uns quilinhos (rsrsrs) nem vou achar ruim de ter menos chocolates este ano. Ok, vamos deixar o coelho pra domingo e vamos trabalhar a nossa dica de hoje.

Em alguns posts atrás eu comentei que o banco de dados normalmente por estigmatização é sempre o primeiro a ser considerado culpado, sobrando para nós DBAs a árdua tarefa de sermos o advogado do dito cujo, tendo que dar o ônus da prova. Ou seja, tendo que provar que não somos o culpado. Afinal de contas, para a maioria dos usuários o banco é o culpado até que se prove o contrário.
Masssssss, nós DBAs sabemos que na grande maioria das vezes existem tantas outras camadas que podem representar esta lentidão: Sistema Operacional, Rede, Aplicação mal escrita, Servidor de aplicação, client do usuário, e por aí vai.

Hoje vamos comentar de uma situação onde foi detectado que o problema não está no banco de dados. Tá bom! Sei que você acabou de pensar: “Se não é no banco de dados eu não tenho nada a ver com isso!”
Certo? ERRADO!!!
Lembra que já comentei da importância de saber fazer, e de quanto é valioso fazê-lo mesmo que faça parte do seu escopo? Então. No mínimo você irá agregar conhecimento e o que é melhor, ajudar/apoiar sua equipe.

Nessa linha vamos imaginar que após o trace, não foi detectada situação que levasse a crer que o problema estaria no banco de dados e necessitasse de investigação nas demais camadas. Eu por default costumo ter como segundo alvo o sistema operacional.

Vamos então imaginar que o nosso ponto de análise é o sistema operacional Linux.
Então como ponto de partida deveremos analisar como o sistema está trabalhando no momento, quais os fluxos de processamento.
Para isso temos diversas ferramentas de apoio, internas e de terceiro, porém hoje vou comentar de uma bem básica mas que traz informações valiosas, o comando top.

Com ele conseguimos ter algumas informações interessantes. Supondo que demos um top no prompt do servidor e ele nos trouxe os dados abaixo:

09:11:01 up 59 min, 12 users, load avg: 4.32, 5.03, 4.72
320 processes: 307 sleeping, 12 running, 1 zombie, 0 stopped
cpu states: 69.8% user 4.6% system 1.5% nice 0.0% iowait  23.9% idle

Primeiramente ele traz:
Data e hora;
Tempo que o servidor está no ar(up);
Quantidade de usuários logados;

Load average(média de carga);
Status dos processos que rodam;
Utilização do CPU.

Que salada de cores né? rsrsrs Vou explicar calma aí…
Com estes dados eu tenho algumas informações importantes claro, como a quantidade de processos, usuários, quando o servidor foi reiniciado, status dos processos rodando… PORÉM (propositalmente em maiúscula para você não deixar de perceber), o mais importante dado é o load average, ele nos trás a média de carga/trabalho do servidor.
Explicando o que estes números nos mostram:
Imagina os números:load avg: 4.32, 5.03, 4.72
O que representam na realidade para nós? Para que servem? Que conclusão ele me leva a ter?
Este números representam exatamente 4,32 é carga de trabalho no momento (é o NOW), 5,03 é referente aos últimos 05 minutos, e 4,72 é referente aos últimos 15 minutos.
Porém estes números me ajudam a calcular um valor MUITO importante que é o load factor(fator de carga). Este é um dado que nos demonstra claramente se o gargalo é na CPU.
Vamos aprender a calculá-lo?  É uma fórmula bem simples:

LOAD FACTOR = LOAD AVERAGE/NUM_CPUS
Análise do resultado de acordo com o valor:
<1 provavelmente o CPU não é o gargalo
>1 Provável problema no CPU

Sei que você acaba de perguntar: “Como pego o valor da quantidade de CPUs?Acertei?
Isso você encontra no arquivo /proc/cpuinfo

Simples não é mesmo? E sendo assim você consegue ajudar a equipe de S.O. e resolver o quanto antes o problema do sistema.

Espero que tenham curtido o post de hoje!!! Ahhhh por falar em curtir, não esqueçam de curtir a fanpage facebook.com/raulfdba, lá você fica sabendo de dicas e novidades do blog.

Grande abraço! Uma feliz Páscoa, com ou sem ovo, o que importa é a união, amizade e coesão das famílias.
FOCO NA METAAAAA!!!!!

Sobre raul andrade

DBA e Instrutor Oracle, apaixonado pela minha família e por ensinar.
Esta entrada foi publicada em DBA Oracle. Adicione o link permanente aos seus favoritos.

2 respostas para Quando o vilão está fora do banco…

  1. Marco Aurelio Peres disse:

    Mais uma vez , Raul, demonstra seu conhecimento e sabedoria na arte de lidar com Banco de Dados.

    Parabéns, por mais um texto de alta qualidade.

Deixe uma resposta