[firebase-br] 100 CPU firebird 2.5 Classic

[Luciano]

Eduardo Jedliczka <edujed em ...> writes:

> 
> COPIE a saída do gstat -h <<banco_de_dados>> aqui para lista... assim
> teremos uma melhor noção do seu ambiente.
> 
> ==========================
> Eduardo Jedliczka
> Apucarana - Pr
> ==========================
> 
> Em 21 de fevereiro de 2011 14:11, Luciano <luciano em ...> escreveu:
> > Fabiano Moura <mctbrasil em ...> writes:
> >
> >>
> >> Ou a query abaixo, porém, para a query ser executada de forma correta, vc
> >> terá que estar com o banco atualizado para Firebird 2.5
> >>
> >> SELECT FIRST 10
> >>   STMT.MON$ATTACHMENT_ID,
> >> STMT.MON$SQL_TEXT,
> >> MEM.MON$MEMORY_USED
> >> FROM MON$MEMORY_USAGE MEM
> >> NATURAL JOIN MON$STATEMENTS STMT
> >> ORDER BY MEM.MON$MEMORY_USED DESC
> >>
> >> *Obrigado,*
> >> *
> >> *
> >> *
> >> *
> >>
> >>
> >
> > No final de semana coloquei com tamanho de página 8192, buffer = 128, e
> > desativei sweep, parecia que ia ficar perfeito, só que as vezes algum 
processo
> > fica 100%, pelo PID eu acabo com ele o sistema estabiliza. Nao acredito ser
> > indice pois os clientes que travão não estão fazendo nada que force o
> > processameto. Alguém sugere algo para teste ?
> >
> >
> >
> >
> > ______________________________________________
> > FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> > Para saber como gerenciar/excluir seu cadastro na lista, use: 
http://www.firebase.com.br/fb/artigo.php?id=1107
> > Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> >
> 
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use: 
http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> 
> 

Olá,

Abaixo segue espeficicações do hardware e o header, mas com algumas conclusões;

Projeto: ERP
Tamanho BD:   2.8 G
Usuários: ~40
Conexões simultâneas:   ^50 (pois alguns abre o aplicativo novamente)

Servidor: Itautec
Processador:  biprocessado com um processador instalado,   XEON
Memoria: 2G
HD: SAS  15 rpm
Controladora com RAID 1 e 128 M cache

Sistema operacional: Fedora 14

Database header page information: 
        Flags                   0 
        Checksum                12345 
        Generation              43499 
        Page size               8192 
        ODS version             11.2 
        Oldest transaction      41847 
        Oldest active           41848 
        Oldest snapshot         41848 
        Next transaction        42589 
        Bumped transaction      1 
        Sequence number         0 
        Next attachment ID      986 
        Implementation ID       19 
        Shadow count            0 
        Page buffers            2048 
        Next header page        0 
        Database dialect        1 
        Creation date           Feb 19, 2011 7:20:23 
        Attributes              force write 
 
    Variable header data: 
        Sweep interval:         0 
        *END* 

Vale destacar que em projetos onde o tamanho do BD e maior e onde a performance 
é pré-requisto, sempre adotavamos a versão Classic, principalmente em linux, e 
sempre utilizei  e sempre funcionou muito bem. Com a intenção de melhorar 
performance e também utilizar os novos recursos, resolvi portar para 2.5, como 
até então sempre obteve melhores resulados, optei pela classic. Mas vale 
observar que durante esse processo, eu ajustei o necessário para 2.5 e instalei 
em um equipamento windows com a superserver para certificação que estava tudo 
pronto para entrar em produção, ficamos uma semana com estes testes. Quando os 
ajustes estavam feitos e tudo parecia OK,  troquei o linux do servidor para 
Fedora 14 e Firebird 2.5 Classic, ai começaram os problemas, conforme os 
usuários vão se conectando e usando o sistema, após 20 conexões e um tempo de 
uso, começa com um processo a consumir 100% da cpu, e influenciando o tempo das 
outras, até que tudo para, não consigo nem conectar mais no BD, isso é um relato 
do acontecido.  Como não há maneira de se trabalhar resolvi testar melhor a 
superserver, pois não ocorre esse problema. E percebi que ela está muito melhor 
em alguns aspectos, o servidor que estou usando tem 2 núcleos, e se eu faço uma 
solicitação de por exemplo um fetch em uma tabela relativamente grande em uma 
conexão e em outra eu fizer outro, no linux, sem nenhuma configuração de cfu 
affinity, ele executa no outro núcleo, e parece-me que bem. Mas resolvemos 
comprar outro servidor mais robusto, mas enquanto isso, resolvi  otimizar 
algumas rotinas no BD com novos os recursos da 2.5 e o desempenho melhorou e 
está sendo usado bem.  Mas o que eu queria era entender o porquê disso, pois 
nesse caso o FB conseguiu me atender, mas se fosse o caso de não conseguir ?, se 
mais alguém precisar do Classic ? 
Eu acredito que seja algo no firebird mesmo,  pois analisei os seguintes pontos

- Tamanho da pagina está 8192 (utilizava deve forma no 1.5)
- Buffers está 2048 (utilizava 10000 no 1.5)

Se fosse indice, rotina não otimizada, no 2.5 ficaria pior que no 1.5 ?, e ainda 
na superserver funcionaria e na classic não ? porque tenho a restartar tudo para 
voltar normal, sendo que somente demoria, mas não para tudo no 1.5. Analisei 
também na semana passada a versão da da GLIBC, que está a 2.12

Se alguém quiser comentar, ou debater