[firebase-br] RES: Help2 , firebird consumindo CPU
Eduardo Jedliczka - TeamFB
jedyfb em gmail.com
Ter Maio 6 09:58:53 -03 2008
Sim, transações de select não commitadas degradam a performance do
banco.
Mas acredito que o FIBPlus à Exemplo do IBO tenha configurações para
tratar as transações....
Sucesso,
Eduardo Jedliczka
Em Seg, 2008-05-05 às 16:55 -0300, Rodrigo A. de Freitas escreveu:
> Eduardo,
>
> Eu tenho um problema similar ao do nosso companheiro. A performance do FB no
> servidor (por coincidência, um Dell 1900 também) degrada horrores quando os
> usuários estão utilizando a todo vapor.
>
> Vendo as estatísticas do banco, eu percebi que estou com cerca de 10 mil
> transações abertas; o problema é que estou usando FIBPlus para acesso, que
> utiliza transações distintas: uma read-only para
> Selects e outra para updates, inserts e deletes. Em todo o sistema estou
> utilizando commits explícitos após cada operação e execução de procedures.
>
> A minha pergunta é: as transações read-only que o FIBPlus mantém aberta (as
> quais não estou comitando explicitamente) também degradam a performance do
> banco ?
>
>
> Atenciosamente,
>
>
> Rodrigo A. de Freitas
> Análise & Desenvolvimento
>
> Soluções & Informática
>
>
> -----Mensagem original-----
> De: lista-bounces em firebase.com.br [mailto:lista-bounces em firebase.com.br] Em
> nome de Eduardo Jedliczka - TeamFB
> Enviada em: segunda-feira, 5 de maio de 2008 15:43
> Para: a.lima.silva em terra.com.br; FireBase
> Assunto: Re: [firebase-br] Help2 , firebird consumindo CPU
>
> Esta lentidão se deve primeiramente ao SWEEP do banco de dados.
> Experimente desativar a sweep (via gfix) e agendar ele para se rodar num
> horário em que não existam usuários conectados (por exemplo: durante a
> madrugada).
>
> Seu outro problema é a quantidade de transações em aberta. à menos que
> você tenha mais de 2 mil usuários, ter mais de 20 mil transações não é
> normal... Lembre-se transações longas (ou seja sem commit) degrada muito
> a performance.
>
> Poucas mudanças no seu aplicativo podem resolver este segundo problema.
>
> Sucesso,
>
> Eduardo Jedliczka
>
> Em Seg, 2008-05-05 às 13:08 -0300, Antonio Carlos escreveu:
> > Alterando o pedido de ajuda, informo que :
> >
> > > Faço a manutenção em um sistema que possui uma base em FB 1.5 com 4GB
> > rodando ate o momento em TS (Terminal Service Windows 2003 Server) .
> >
> > > São 15 estações acessando o TS em um servidor Dell 1900 Xeon Dual Core
> > com 4GB ram e derrepente numa das atualizações do banco a performance
> > despencou,
> > ao monitorar o W2003 percebi que o FB utilizava apenas um dos nucleos do
> > xeon dando piques quase constantes de 90-100%, por esta observação entendi
> > que seria uma medida correta trocar o Fb de lugar e deixar de rodá-lo
> > localmente ( 127.0.0.1 <http://127.0.0.1/> ).
> >
> > > Para evitar gargalos, fiz um link de 1000Mbps no dell 1900 e um
> servidor
> > Dell 830 com 2 GB Ram e P4 no qual instalei o Fedora 7 rodando em modo
> > texto. Resolvi a dependencia da lib e instalei o FB 1.5. SUPER SERVER
> >
> > > Fiz backup do banco e restore no linux, e observei que com poucas
> > estações conectadas o sistema "voava", mas para minha surpresa quando
> todos
> > conectaram, a lentidão reapareceu nos mesmos niveis anteriores. Com o
> > comando Top pude verificar que com as 15 estações acessando é
> > consumido CPU ( 94 COM PIQUES DE 101%) no processo do FB.
> >
> > > Estranho foi que não vi uma melhora de performance do TS mesmo tendo
> > sido liberado pelo menos 1.2 GB ram.
> >
> > > Existe uma forma de se verificar se esse sistema esta deixando
> Transações
> > abertas e isso esta degradando o banco ?
> >
> > IMPORTANTE O BANCO FOI RESTAURADO COM A MESMA PAGE SIZE
> >
> > RODEI GSTAT ABAIXO :
> >
> > Database header page information:
> > Flags 0
> > Checksum 12345
> > Generation 48931
> > Page size 4096
> > ODS version 10.1
> > Oldest transaction 24710
> > Oldest active 28043
> > Oldest snapshot 28042
> > Next transaction 48924
> > Bumped transaction 1
> > Sequence number 0
> > Next attachment ID 0
> > Implementation ID 19
> > Shadow count 0
> > Page buffers 0
> > Next header page 0
> > Database dialect 3
> > Creation date May 2, 2008 12:52:30
> > Attributes force write
> >
> > Variable header data:
> > Sweep interval: 20000
> > *END*
> >
> >
> >
> > Database log page information:
> > Creation date
> > Log flags: 2
> > No write ahead log
> >
> > Next log page: 0
> >
> > Variable log data:
> > Control Point 1:
> > File name:
> > Partition offset: 0 Seqno: 0 Offset: 0
> > Control Point 2:
> > File name:
> > Partition offset: 0 Seqno: 0 Offset: 0
> > Current File:
> > File name:
> > Partition offset: 0 Seqno: 0 Offset: 0
> > *END*
> >
> >
> >
> > []s.
> > Antonio Carlos
> >
> >
> >
> >
> >
> > ______________________________________________
> > FireBase-BR (www.firebase.com.br <http://www.firebase.com.br/> ) -
> Hospedado
> > em www.locador.com.br <http://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
> >
> >
> >
> > No virus found in this incoming message.
> > Checked by AVG.
> > Version: 8.0.100 / Virus Database: 269.23.8/1415 - Release Date:
> 05/05/2008
> > 06:01
> >
> >
> > ______________________________________________
> > 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
>
>
>
Mais detalhes sobre a lista de discussão lista