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

Renan Cruz de Almeida renan.aju em terra.com.br
Ter Ago 19 16:40:22 -03 2008


Pergunta : Será que usando a versão Classic, numa máquina com mais de um 
processador, surtiria uma melhora na performance?

Renan.


Rafael Helm - Trevisan Tecnologia escreveu:
> 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
> 




Mais detalhes sobre a lista de discussão lista