[firebase-br] Help2 , firebird consumindo CPU

Welkson Renny de Medeiros welkson em gmail.com
Seg Maio 5 16:00:31 -03 2008


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 





Mais detalhes sobre a lista de discussão lista