Fórum Lentidão num select count #490007
25/08/2014
0
Estou a alguns dias enfrentando um problema estranho.
Na tabela clientes, tenho em torno de 25000 registros.
No início de cada dia o acesso a essa tabela é muito demorado, depois fica rápido.
Em testes aqui na empresa, tento dar um "select count(*) from clientes", demora em torno de 4 minutos, depois repito o mesmo comando e a resposta é instantânea.
Já removi todos os indíces e os refiz e continua.
Já fiz backup/restore e continua.
att
Mario
Mario Inacio
Curtir tópico
+ 0Posts
25/08/2014
Alex Lekao
Qual o banco vc esta usando?
Gostei + 0
25/08/2014
Mario Inacio
Firebird 2.5
Gostei + 0
25/08/2014
Marisiana Battistella
Como é uma quantidade enorme de registros, pode ser normal demorar na primeira execução...
Gostei + 0
25/08/2014
Marisiana Battistella
Gostei + 0
25/08/2014
Alex Lekao
Acredito que ate possa ser o cache, embora nao sei se o Firebird armazene em cache uma especie de view daquilo que foi executado.
Nao tenho tanta experiencia com tudo isso.
Vc percebe se eh sempre apos alguma coisa mais especifica? esse select que vc menciona fazer eh a primeira coisa a ser executada no dia?
Lembro-me que o firebird tinha umas questoes que deixava as execucoes todas lentas, o Garbage Colector(acho que eh assim que escreve, faz muito tempo. rsrs), e sempre apos ele ser executado tudo ficava normal, era uma rotina que funcionava automatizada no Banco, nao tinha intervencao nossa, mas lembro-me que ele acontecia sempre qdo no banco uma quantidade era atingida, nao me lembro exatamente o que, mas lembro-me que o valor era 20000, o Firebird armazena alguns registros, acho que referente as transactions, e qdo esse diferenca atinge 20000 ele roda o GC automaticamente, como disse nao me lembro exatamente.
Mas no nosso cara coincidentemente acontecia sempre as 16 horas.
Vc percebeu se tem alguma situacao especifica que dispara a melhora da performance? o banco eh desligado? coisas deste tipo.
Desculpe nao ajudar mais.
Abraco.
Gostei + 0
25/08/2014
Mario Inacio
Essa lentidão ocorre todo dia pela manhã na primeira execução.
Acredito não ser pela quantidade de dados da tabela pois no mesmo banco há uma tabela com 100 mil registros e é executado rapidamente.
É somente nessa tabela clientes, inclusive deletei campos que eram "blob" mas de nada resolveu.
Vou dar uma olhada sobre GC.
Gostei + 0
25/08/2014
Alex Lekao
Sugiro tambem verificar sobre dependencias da tabela.
Talvez vc tenha que deletar e criar novamente, nao sei, eh uma hipotese.
Desculpe por nao poder ajudar.
Abraco.
Gostei + 0
25/08/2014
Marisiana Battistella
Encontrei no link (clique aqui) algumas dicas de como melhorar a performance do firebird e tem uma delas que fala o seguinte sobre o GC sobre o GC...
O Firebird tem por padrão a função de automaticamente limpar as antigas versões dos registros quando estas se tornam muito numerosas. O problema deste método é que se um processo cliente que for sem sorte suficiente para iniciar uma transação que coincida com o início da limpeza automática, vai ter que esperar o trabalho de limpeza. O processo clienteatrasa enquanto o processo de limpeza é feito. Desabilite a limpeza automática (automatic garbage collection), usando GFIX –h 0, em favor da limpeza programada (scheduled database sweep), usando GFIX –s. Isto irá eliminar a perda na performance do cliente.Fazer um backup e restore efetivamente faz a mesma coisa do que uma limpeza completa no banco de dados. O backup somente copia a versão mais recente de cada registro, nunca copia versões anteriores, assim, quando os dados são restaurados, existe somente uma versão de cada registro. Existem também outros benefícios de fazer backup/restore,descritos na seção própria deste artigo. Falando em limpeza do lixo, muitos programadores não se dão conta da necessidade de iniciar e terminar (START e COMMIT) suas transaçõescom o banco de dados. Abrir transações impede que a varredura periódica complete a limpeza do lixo, e a performance irá sofrer progressivamente com o tempo.
Gostei + 0
25/08/2014
Alex Lekao
Eu tive que desabilitar o GC e rodar manual todos os dias, na epoca estava estudando a possibilitade de criar uma rotina na cron do linux para fazer na madrugada, ate cheguei a achar algumas dicas na epoca mas acabei nao levando adiante pq a empresa decidiu trocar de ERP.
Gostei + 0
25/08/2014
Mario Inacio
Vou fazer um backup\restore desabilitando o GC pra testar.
Amanhá pela manhã terei o resultado daí posto aqui.
O mais intrigante é que tenho 500 instalações do meu sistema e somente em alguns está ocorrendo esse problema no banco.
Por enquanto obrigado.
Gostei + 0
25/08/2014
Marisiana Battistella
Gostei + 0
25/08/2014
Alex Lekao
Eh possivel que seja o GC mesmo.
Ja que nao esta acontecendo em todos.
Gostei + 0
29/08/2014
Mario Inacio
Fiz o backup/restore desativando do GC e incrivelmente continua com o mesmo problema.
Na primeira consulta da manhã a consulta a tabela clientes continua lenta, depois fica normal.
Gostei + 0
29/08/2014
Alex Lekao
Vc chegou a testar alguma coisa referente aquilo que a Marisiana postou como citacao acima?
Acredito que talvez vc deva fazer o GC manualmente para testar.
Vou colocar o que eu fazia aqui no trabalho.
Ao final do expediente eu fazia a limpeza manual, executava o comando referente ao GC e durante a noite era feito o backup automaticamente, no outro dia estava tudo funcionando normalmente sem a lentidao.
Acredito que para tirarmos a duvida, vc tera que desabilitar o GC e roda-lo manualmente ao final do dia por exemplo, ou em outro momento que possibilite faze-lo.
Espero que ajude.
Abraco.
Gostei + 0
01/09/2014
Claudio Ferreira
http://www.percona.com/blog/2007/04/10/count-vs-countcol/
A tabela tem indices criados ? experimente dar select Count(nomedocampo) num campo com índice.
Veja também o explain plan, se não melhorar tem a ver com o firebird (configuração e tunning) ou mesmo a máquina pode estar com problema.
Gostei + 0
Clique aqui para fazer login e interagir na Comunidade :)