[firebase-br] RES: Alocação de processamento

Rafael Helm - Trevisan Tecnologia rhelm em trevisantecnologia.com.br
Ter Ago 19 16:25:44 -03 2008


Obrigado Cantu, não tinha me dado conta desta questão do sweep.

Mas o problema ocorre em virtude de consultas muito pesadas na base, porém
nem sempre é possível evitar que algum usuário solicite um relatório pesado
ou que até mesmo o administrador execute erroneamente consultas SQL que
"pendurem" o servidor.

Ou seja, a causa do problema é conhecida, o que eu gostaria é de verificar
com os colegas é se existe alguma forma de reduzir o impacto da execução
destas consultas para os outros usuários.

É possível definir prioridades para os usuários do Firebird?


Rafael Helm.

-----Mensagem original-----
De: lista-bounces em firebase.com.br [mailto:lista-bounces em firebase.com.br] Em
nome de Carlos H. Cantu (TeamFB)
Enviada em: terça-feira, 19 de agosto de 2008 15:49
Para: FireBase
Assunto: Re: [firebase-br] Alocação de processamento

Infelizmente, como o FB ainda não suporta totalmente SMP, a melhor
opção que você tem hoje é detectar quais as operações que estão
gerando 100% de carga, e ver se é possível otimiza-las de forma que
consumam menos processamento.

Fique atento quanto a índices redundantes ou com baixa seletividade,
ou então com a falta de índices que poderiam auxiliar as pesquisas nas
tarefas executadas, etc.

Veja tb se a culpa não é o sweep automático. Se for o caso, desligue
ele, e agende um sweep manual de madrugada (quando o servidor estiver
light). Como vc tem milhares de transações por dia, pode ser que o
sweep esteja sendo disparado diversas vezes num mesmo dia.

[]s
Cantu (Membro do TeamFB - FireBase)
http://www.warmboot.com.br
FireBase - http://www.FireBase.com.br
Blog - http://blog.firebase.com.br

RHTT> Olá pessoal,

RHTT>  

RHTT> Escrevo para compartilhar com a lista um problema que estou
enfrentando,
RHTT> primeiro listo algumas características importantes: 

RHTT>  

RHTT> * Tenho um banco FB com pouco mais de 1Gb, com page size de 16K, e
dialeto
RHTT> 3. Estou utilizando a versão 1.5.x do FB.

RHTT>  

RHTT> * Durante o dia ocorrem milhares de rápidas conexões com este banco de
RHTT> dados, 90% não chegam a durar nem 1 segundo.

RHTT>  

RHTT> * Nestas conexões uma aplicação desenvolvida com D7 (dbexpress)
executa
RHTT> consultas, e algumas operações básicas de insert, update e delete.

RHTT>  

RHTT> * Como a aplicação está respondendo a requisições de dispositivos
móveis, em
RHTT> virtude do time out destes dispositivos minhas respostas precisam ser
muito
RHTT> rápidas.

RHTT>  

RHTT> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

RHTT>  

RHTT> Meu problema é o seguinte:

RHTT>  

RHTT> - Ao rodar alguns procedimentos mais pesados no banco de dados, a
alocação
RHTT> do processador vai a 100% e consequentemente todas aquelas conexões
que
RHTT> geralmente não duram nem 1 segundo acabam ficando “travadas”.

RHTT>  

RHTT> - Existe alguma forma de configurar para o firebird trabalhar com
processos
RHTT> efetivamente “paralelos”, de modo a uma conexão muito pesada não
“travar”
RHTT> todas as outras?

RHTT>  

RHTT> Obs.: Todas as conexões usam o mesmo usuário de banco de dados, pode
ser
RHTT> este o motivo?

RHTT>  

RHTT> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

RHTT>  

RHTT> Desde já obrigado.

RHTT>  

RHTT> Rafael Helm 

RHTT>  




______________________________________________
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

-- 
Esta mensagem foi verificada pelo sistema de antivírus e
 acredita-se estar livre de perigo.

No virus found in this incoming message.
Checked by AVG - http://www.avg.com 
Version: 8.0.138 / Virus Database: 270.6.5/1620 - Release Date: 19/8/2008
06:04


-- 
Esta mensagem foi verificada pelo sistema de antivírus e
 acredita-se estar livre de perigo.





Mais detalhes sobre a lista de discussão lista