Entendendo o 'lixo' no BD http://www.firebase.com.br/fb/artigo.php?

id=2047

Usuários: 40549
Artigos: 167
Dicas: 111
Downloads: 264
15.05.09

Entendendo o 'lixo' no BD
Não é raro encontrar pessoas que não dão a devida importância a um controle transacional correto no banco de dados.
Geralmente, são essas pessoas que costumam sofrer com problemas de performance, e que geralmente preferem culpar o SGBD
ao invés de procurar o real motivo do problema.

Quedas de performance abruptas, sem razão aparente, podem indicar que um sweep está sendo executado. Podemos dizer, de
forma geral, que um sweep é uma limpeza de lixo (garbage collection) generalizada, executada no banco de dados. Mas o que é a
garbage collection e porque existe “lixo”?

A primeira coisa a saber é que o Firebird utiliza um sistema de controle de concorrência chamado MGA (Multi Generational
Architecture). Isso significa que dentro de um banco de dados Firebird, podem existir diversas versões de um mesmo registro,
cada uma delas apresentando informações válidas em um determinado momento no tempo. Com isso, é possível ter transações
enxergando dados que já foram apagados por uma outra transação. Os dados apagados podem continuar existindo para algumas
transações, dependendo do isolamento transacional que elas utilizam e do momento em que foram iniciadas. É por isso também
que diferentes transações podem enxergar valores diferentes de um mesmo registro.

Para que a MGA funcione, tudo que for feito no Firebird, até mesmo um simples select de leitura, deve estar associado a uma
transação. Pode parecer confuso, mas tudo fica claro a partir do momento que você entende como os diferentes isolamentos
transacionais influenciam a visão dos dados.

O fato é que, para manter as diferentes visões de um mesmo registro, o Firebird mantém versões temporárias dos dados. A partir
de um determinado momento, esses registros temporários não são mais necessários. Mas eles existem e ocupam espaço dentro
do arquivo do banco de dados. Dependendo do número de acessos e operações concorrentes sendo realizadas no BD, a
quantidade de “lixo” gerada pode fazer com que o arquivo do banco de dados cresça rapidamente. O processo de Garbage
Collection existe justamente para identificar esses espaços que foram usados e que não são mais necessários, e marcá-los como
reaproveitáveis. Sendo assim, da próxima vez que o Firebird precisar gravar alguma informação no banco, ele usará os espaços
previamente alocados, ao invés de pedir que o sistema operacional aloque mais espaço, o que aumentaria o tamanho do arquivo e
prejudicaria a performance (alocar espaço é sempre mais lento do que reutilizar um espaço já alocado). Registros apagados
também são um exemplo de lixo ocupando espaço que pode ser reaproveitado.

Dependendo da versão e da arquitetura do Firebird utilizada (CS x SS), a coleta de lixo pode se dar de duas formas:

Cooperativa – Presente no servidor Classic. Nesse modelo, a transação que está lendo os registros é responsável por identificar
a existência de lixo e fazer a limpeza. Isso significa que se você der um select em uma tabela, e ele encontrar muito lixo pelo
caminho, a performance deste select será prejudicada, pois ao mesmo tempo em que está recuperando as informações, está
também fazendo a limpeza. Faça um teste: pegue uma tabela que contenha alguns milhões de registros e apague todos eles
(delete). Dê um commit, e depois rode um select * nessa mesma tabela. Você verá que o select vai demorar certo tempo para
retornar “nada” (a tabela está vazia). Isso porque, encontrando as condições propícias, ele realizou a limpeza do lixo. Se rodar o
select novamente, ele será rápido (pois o lixo já foi coletado).

Background – Presente no servidor SuperServer. Nesse modelo, a transação que está lendo os registros, identifica a existência
de lixo e notifica a thread de Garbage Collection para que ela realize a limpeza assim que possível.

Combined – Esse modo foi introduzido no FB 2.0, e funciona apenas com o SuperServer. Como o próprio nome sugere, ele é
um híbrido entre o modo Cooperativo e Background, e passou a ser o modo padrão de GC no SS. Através do firebird.conf, ainda é
possível alterar para o modo Background ou Cooperative.

Mas e o Sweep? Como dito anteriormente, o sweep pode ser considerado como uma faxina geral no banco. Além de fazer a GC,
ele também atualiza a OIT (Oldest Interesting Transaction) sempre que possível. Por padrão, bancos Firebird são configurados
para disparar um sweep automático quando a diferença entre a OAT (Oldest Active Transaction) e a OIT atinge 20.000. Acontece
que se isso acontecer em um momento em que o servidor esteja com uma grande carga de processamento, com inúmeras
requisições, os usuários vão sentir uma queda repentina de performance. Neste caso, é aconselhável desligar o sweep automático
(através do gfix), e agendar um sweep manual para que seja executado em um horário onde o servidor não esteja com muita
carga (por exemplo, de madrugada).

A quantidade de lixo gerado em um banco de dados depende principalmente do controle transacional. Em ambientes de grande
concorrência e com muitas alterações de dados, transações que ficam abertas por muito tempo podem gerar uma grande
quantidade de lixo, prejudicando também a performance do servidor.

É muito importante que todos os usuários do Firebird entendam como a MGA funciona, para que não sejam pegos de surpresa
com problemas de performance “misteriosos”. Na FireBase, temos artigos que explicam isso. Para os que desejarem uma
informação mais “hardcore” sobre performance, a FireBase lançou recentemente uma vídeo aula de 3h dada por Dmitry Yemanov
(chefe da equipe de desenvolvimento do FB), intitulada “Firebird Performance in Detail”. Essa vídeo aula traz informações

1 de 2 15/05/2009 15:31
Entendendo o 'lixo' no BD http://www.firebase.com.br/fb/artigo.php?id=2047

preciosas, e que não são encontradas facilmente por aí. Mais informações em http://videos.firebirddevelopersday.com.br. Os
CDs/DVDs do Firebird Developers Day (disponíveis na loja on-line da FireBase) também contém palestras que tratam deste
assunto.

Conclusão: se você tomar os devidos cuidados com suas transações e com o sweep, dificilmente terá problemas de performance
com o Firebird.

Autor: Carlos H. Cantu

Artigo originalmente publicado na revista ActiveDelphi.

Avalie esse artigo/dica:

Comentários

Não há comentários para esse item...

Atenção! Não poste dúvidas nos comentários. Para obter suporte, use a lista de discussão da FireBase.

Copyright (C) Carlos H. Cantu - É proibida a reprodução de qualquer material desse site sem autorização prévia

2 de 2 15/05/2009 15:31