Gargalo.
Bom dia, boa tarde, boa noite!
Fala a verdade, você já pensou em tomar uma né? Já imaginou aquela gelada descendo pelo gargalo…
OK, imagina então que a cerveja congelou um pouco e pelo gargalo desce muito pouquinho líquido “precioso”.
Exatamente isso… Não! Ainda não estou louco! É apenas uma representação do que pode acontecer em qualquer ambiente de TI o temido gargalo.
Esse nome é dado a todo fluxo que acaba ocorrendo lentidão, espera, ou seja, algum tipo de demora, devido a algo ocasionando barreira.
Como já conversamos anteriormente nos posts que iniciaram os estudos de OWI (Oracle Waits Interface) existem diversos eventos que fazem com que o nosso processo fique demasiadamente lento.
Normalmente a lentidão é sentida pelo usuário final na célebre frase: “Tá lento!!!” Opa!!! Lembra?? “Demostre talento quando tudo tá lento???”
Exatamente isso. Descobrir onde está o gargalo é a primeira etapa do nosso processo. Então para descobrir quais eventos de espera estão ocorrendo no banco de dados temos o script já citado em post anterior (dá uma procurada lá qualquer coisa me avisa) Cada vez que ele roda descobre alguns eventos de espera que podem ser importantes ou não.
Hoje especificamente vou comentar a respeito de um evento que pode ser, vamos dizer, até normal, desde que não esteja impactando negativamente o ambiente.
O evento de hoje tem um nome bem estranho, é o “resmgr:cpu quantum”.
Quando este evento de espera ocorre teremos que saber que está diretamente ligado a Hardware x Gerenciador de Recursos Oracle, o Resource Manager.
Este evento, embora tenha um nome estranho, ele nada mais é do que dizer que a sessão que tem este evento está esperando para utilização de CPU.
Neste caso temos duas situações que podem estar causando isto e podem ser analisadas, ou o resource manager está sendo utilizado e está restringindo quantidade de utilização de CPU para o usuário que está efetuando a transação, ou temos mais de uma instância no mesmo servidor.
Neste segundo caso, todo DBA tem em mente que Instâncias de produção não devem habitar mesmo servidor (rsrsrs)ou seja, cada instância no seu servidor dedicado.
Porém, a prática mostra que nem sempre isso acontece, sendo assim teremos que verificar o parâmetro de inicialização de ambas como está o item cpu_count.
Para isso utilize o script:
select * from v$parameter where name like ‘%cpu%’;
Faça isso em ambas as instâncias e verifique que a soma de todos não deveria ultrapassar a quantidade total de CPUs do servidor, caso isso aconteça poderá ocorrer que uma instância irá atrapalhar a outra em certos momentos.
Também poderemos descobrir como está no Sistema Operacional UNIX com o vmstat:
Verifica-se quando a coluna de fila de execução (r) exceder o cpu_count do banco de dados.
Simples não é mesmo? Lembrando que geralmente isso não costuma causar impactos muito relevantes, mas caso ocorram, a dica será muito útil.
Grande Abraço! Espero que tenha curtido, que me pergunte sobre as dúvidas. E Não esqueça!!! Foco na meta!!!!
