Pular para o conteúdo

Quem está comendo minha CPU ?

Um dos grandes desafios do DBA é identificar qual o processo que está “comendo” a CPU e Memória e Disco.
Depois de identificar, o novo desafio é trabalhar o processo de forma a deixar de ser um glutão de recursos e tornar-se um aliado da performance.
Dividirei em três partes esses grandes glutões.
Primeiro, aquele que destroi a CPU…
Alguns processos podem consumir 100% de CPU sem grande dificuldade, inclusive de identificar esse tipo de glutão. São aquelas consultas mal desenvolvidas ou extremamente complexas, as principais vilãs são as que possuem consultas recursivas e sub-consultas.
Segundo, aquele que consome a Memória…
São aquelas consultas com o famoso “select * from tabela”. Essas consultas tem dois crimes graves associados a ela, traz todas as colunas da tabela e não tem restrições nem parâmetros, portanto não usa índice. Outras vilãs, são as consultas que fazem produto carteziano, isto é, em alguma das tabelas referenciadas não é usado o índice, acaba acontecendo que, para cada linha consultada o SGBD é obrigado a verificar toda a tabela, gerando um consumo de Memória absurdo e CPU também.
Terceiro e não menos importante, o devorador de Disco…
Existem dois casos bastante claros de devoradores de discos, pouca memória ou uso excessivo de memória pode gerar swap, isto é, o SGBD acaba usando o disco para auxiliar a memóra. Outro grande glutão é a péssima modelagem de dados, em algum tempo / espaço algum lunático disse que é interessante ter os dados duplicados pois facilita consultas, portanto você acaba tendo a informação duplicada em diversas tabelas ao invés de ter somente as chaves de referência, isso acaba gerando um consumo desnecessário por disco, que depois de algum tempo mostra-se um grande vilão,

O que fazer para deter esses grandes vilões ?

  1. Ter sempre um AD ou pelo menos um DBA para auxiliar na confecção de projetos de Bancos de Dados, pois modelar o banco de acordo com as telas, como muito desenvolvedor faz, é um grande erro.
  2. As consultas mais complexas devem ser sempre desenvolvidas em conjunto com um DBA qualificado, pois existem mais recursos dentro de um SGBD do que sugere a nossa vã filosofia.
  3. Consultas não são otimizadas apenas pelo “custo”, mas tem que ver a cardinalidade e I/O também, aliás, todo o trace deve ser cuidadosamente analisado.
  4. Configurar o banco de acordo com a necessidade do cliente, pois cada cliente tem uma necessidade e cada necessidade requer um tipo de atenção diferenciada, instalar bancos “padrão” só serve para pequenas empresas, mesmo assim com restrições.
  5. Atenção especial ao dia a dia, todos os detalhes tem que ser verificados e comparados com os dias anteriores para se evitar distorções e surpresas desagradáveis.

Quão útil foi este post ?

Clique em uma estrela para classificar o post

nota média 0 / 5. Contagem de votos: 0

Sem votos ! Seja o primeiro a classificar !

Marcações:

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

plugins premium WordPress