[firebase-br] LockMemSize

Jorge Henrique - Depto TI jorgehenrique em americamoveis.com
Ter Out 4 08:22:22 -03 2005


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
> ========================= 






Mais detalhes sobre a lista de discussão lista