[firebase-br] Help2 , firebird consumindo CPU
Eduardo Jedliczka - TeamFB
jedyfb em gmail.com
Ter Maio 6 10:03:06 -03 2008
sim (eu estou com o FB 1.5 na minha frente):
gfix -user SYSDBA -password masterkey -housekeeping 0
dbserver:/db/mydb.fdb
gfix -user SYSDBA -password masterkey -sweep dbserver:/db/mydb.fdb
Sucesso,
Eduardo Jedliczka
Em Seg, 2008-05-05 às 16:00 -0300, Welkson Renny de Medeiros escreveu:
> Eduardo,
>
> Só confirmando os procedimentos... primeiro eu teria que desativar o sweep:
>
> gfix -user SYSDBA -password masterkey dbserver:/db/mydb.fdb -h 0
>
> Depois criar algum tipo de batch (Win) ou cron (Unix) para rodar o sweep
> manualmente, mais ou menos assim:
> gfix -user SYSDBA -password masterkey dbserver:/db/mydb.fdb -sweep
>
> Confere?
>
>
> --
> Welkson Renny de Medeiros
> Focus Automação Comercial
> Desenvolvimento / Gerência de Redes
> welkson em focusautomacao.com.br
>
>
>
> Powered by ....
>
> (__)
> \\\'',)
> \/ \ ^
> .\._/_)
>
> www.FreeBSD.org
>
>
> ----- Original Message -----
> From: "Eduardo Jedliczka - TeamFB" <jedyfb em gmail.com>
> To: <a.lima.silva em terra.com.br>; "FireBase" <lista em firebase.com.br>
> Sent: Monday, May 05, 2008 3:42 PM
> Subject: 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
>
>
> ______________________________________________
> 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