[firebase-br] 100 CPU firebird 2.5 Classic

Eduardo Jedliczka edujed em gmail.com
Seg Fev 28 22:40:19 -03 2011


O seu problema com o Classic se resume à falta de memória.

2048 páginas * 8KB por página = 16 MB por usuário + 20MB a 28 MB (se
estiver com os valores padrões para SORT, TEMP, etc).

Resultando em aproximadamente 40MB a 48MB por terminal * 50 usuários =
2000MB a 2500MB.

Como você tem míseros 2048MB de ram, o resto irá para o SWAP, tornando
o desempenho pior do que uma lesma "carregada" na subida.

Pelo tamanho do seu banco, o Classic só seria aconselhável se houvesse
pelo menos 4 GB de ram.

Já com o superserver, usando menos de 150 MB para todas as conexões, e
deixando 1.8GB entre cache de disco e S.O. a performance certamente
será melhor, mesmo usando APENAS um núcleo físico.

==========================
Eduardo Jedliczka
Apucarana - Pr
==========================




Em 23 de fevereiro de 2011 09:24, Luciano <luciano em orgsystem.com.br> escreveu:
> 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
>
>
>
>
> ______________________________________________
> 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
>




Mais detalhes sobre a lista de discussão lista