[firebase-br] LockMemSize
Jorge Henrique - Depto TI
jorgehenrique em americamoveis.com
Ter Out 4 14:37:05 -03 2005
Ok, beleza.....Vamos lá!!
Os dados do gstat:
Database header page information:
Flags 0
Checksum 12345
Generation 45587
Page size 8192
ODS version 10.1
Oldest transaction 42218
Oldest active 45572
Oldest snapshot 45572
Next transaction 45574
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 Sep 22, 2005 12:21:42
Attributes force write
Variable header data:
Sweep interval: 20000
*END*
O sistema foi feito em Delphi 7, com MDO 0.9.0, a máquina servidora é um P4
2.4 com 512 de RAM e HD (IDE) de 120 GB, meu servidor FB 1.5.3.4842 NPTL
SuperServer.
Então, eu li o livro do Cantu e "repassei" todas as transações do meu
sistema. Realmente havia algumas q estavam mal configuradas e eu as corrigi,
mas se foram 10% de acerto, foi muito...
Mais uma vez, obrigado pela atenção...
Jorge Henrique.
----- Original Message -----
From: "Eduardo Jedliczka (TeamFB)" <jedyfb em gmail.com>
To: "FireBase" <lista em firebase.com.br>
Sent: Tuesday, October 04, 2005 1:04 PM
Subject: Re: [firebase-br] LockMemSize
> Bom, vamos às Respostas...
>
> Em que linguagem seu sistema Foi feito ??? Qual componente de acesso você
> utiliza ??? Componentes específicos para InterBase/FireBird possuem
> melhores dispositivos para descobrir problemas transacionais.
>
> Você disse que está lendo o livro do Cantu, e que está "acertando" as suas
> transações... poderia enviar a primeira parte de um GSTAT para a lista, a
> fim de vermos os valores sobre a transação atual, mais antiga aberta e a
> próxima ???
>
> =========================
> Eduardo Jedliczka
> (Membro do TeamFB)
> Apucarana - Pr
> =========================
>
> ----- Original Message -----
> From: "Jorge Henrique - Depto TI" <jorgehenrique em americamoveis.com>
> To: "FireBase" <lista em firebase.com.br>
> Sent: Tuesday, October 04, 2005 8:22 AM
> Subject: Re: [firebase-br] LockMemSize
>
>
> Eduardo,
>
> Obrigado pelas dicas!!
>
> Estou com esse problema de queda no meu servidor FB já faz tempo. Tenho
> tentado de todas as formas contornar os vários itens que podem ocasionar
> esses problemas, tais como: placas de redes defeituosas, cabos velhos e
> mal
> passados, plugs, tenho feito manuntenções no meu servidor linux, mantenho
> meu servidor FB atualizado, etc. E até agora nada adiantou. A questão é
> que
> não sei mesmo o que está provocando a minha "dor de cabeça".
>
> E respondendo as suas colocações:
>
> 1) Ainda não tenho muitos usuários fazendo inserções, updates e deletes. O
> que tenho visto é em torno de 5 até 8 e nunca passou dessa quantidade.
> Isso
> me deixa preocupado, pois, quando entrar em produção total, posso ter
> muitos
> usuários conectados, haja visto que possuo soluções em PHP, com
> web-hosting
> e tudo.
>
> 2) Analisando meu banco de dados, creio que não é essa a causa principal.
> Mas como posso tirar a prova disso??? Há como monitorar essas páginas
> "lockadas"?
>
> 3) Já repassei por todo meu controle transacional e, de acordo com o que
> aprendi no livro do Cantu, está tudo em ordem com as transações.
>
> Todos os dias, antes de ir embora eu dou um shutdown no banco e passo um
> gfix. Já tive alguns problemas mas foram facilmente resolvidos com
> backup/restore.
>
> ----- Original Message -----
> From: "Eduardo Jedliczka (TeamFB)" <jedyfb em gmail.com>
> To: "FireBase" <lista em firebase.com.br>
> Sent: Tuesday, October 04, 2005 12:52 AM
> Subject: Re: [firebase-br] LockMemSize
>
>
>> Jorge...
>>
>> Aumentar o LockMemSize pode "amenizar" o seu problema... é como tomar
>> remédio para dor de cabeça... ela passa, mas você sabe o que causava a
>> dor de cabeça ???
>>
>> Depois de quebrar a cabeça para resolver um problema de Lock, descobri
>> que há apenas 3 possibilidades para que 96KB sejam pouco:
>>
>> 1º) Você tem muitos usuários simultâneos fazendo deletes e updates...
>> enquanto não é dado um commit e/ou rollback, o banco mantém o lock na(s)
>> pagina(s) que os dados, e seus índices estão armazenados...
>>
>> 2º) Você tem muitas conexões curtas sobre poucos registros, ou em outras
>> palavras, imagine uma tabela que é alterada frequentemente por muitos
>> usuários, mas tem pouquíssimos registros... uma hora ou outra você vai
>> incluir, alterar ou apagar um registro, que está numa página
>> "bloqueada"... só que enquanto este lock não é liberado, o banco vai
>> bloqueando outras páginas até que .... bum.... não tem mais páginas
>> livres...
>>
>> 3º) Modelo transacional errado ou incoerente... Ou em outras palavras,
>> transações muito longas, (em tempo ou em quantidade de páginas alteradas)
>> que não foram finalizadas.
>>
>> Isto desconsiderando o problema de hardware, problema de outros softwares
>> ou de banco corrompido, pois aí não tem regra...
>>
>> mas só para responder, PORQUE A PERFORMANCE MELHOROU ???? imagine um
>> arquivo (de metal) com várias gavetas, se tem mais gavetas, existe uma
>> probabilidade maior de que você encontre uma gaveta vaga com poucas
>> tentativas....
>>
>> =========================
>> Eduardo Jedliczka
>> (Membro do TeamFB)
>> Apucarana - Pr
>> =========================
>
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> Para editar sua configuração na lista, use o endereço
> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.bavs.com.br
> Para editar sua configuração na lista, use o endereço
> http://mail.firebase.com.br/mailman/listinfo/lista_firebase.com.br
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>
Mais detalhes sobre a lista de discussão lista