[firebase-br] RES: Help2 , firebird consumindo CPU
Rodrigo A. de Freitas
rodrigo em solucoeseinformatica.com.br
Seg Maio 5 16:55:38 -03 2008
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
--
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 269.23.8/1415 - Release Date: 5/5/2008
06:01
Mais detalhes sobre a lista de discussão lista