[firebase-br] RES: RES: Lentidão

Maciel Soncini Bueno maciel em 2msolutions.com.br
Ter Maio 27 11:19:26 -03 2008


Eduardo,

De ontem para hoje desliguei o Sweep automático e coloquei para fazer logo após o backup (22h00).

Tive o retorno hoje dos usuários e dos testes que realizei que a performance do sistema está excelente, voando baixo.

Atenciosamente,

Maciel Soncini Bueno
2M SOLUTIONS
11-4438-6891 / 8555-8507
maciel em 2msolutions.com.br
www.2msolutions.com.br


-----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, 26 de maio de 2008 20:52
Para: FireBase
Assunto: Re: [firebase-br] RES: Lentidão

Maciel, fiquei muito satisfeito de ver suas respostas... mais uma vez,
peço-lhe desculpas pela aspereza em lhe responder (infelizmente, meu
excesso de objetividade, causa muitas vítimas).

Sobre livros e documentação este é um problema sério do Firebird (à
exemplo de muitas outras ferramentas open-source excepcionais), mas
sugiro participar mais de fóruns (como este aqui, que há muitas pessoas
capacitadas) e ler os livros do CANTU e da Hellen Borrie (Dominando o
Firebird)... há alguns PDFs e artigos interessantes nos poucos sites
específicos sobre firebird... Um ponto de partida é o próprio site da
Firebase. outra sugestão é o site da IBPHOENIX (há artigos antigos quase
todos pré-FB 1.0, mas muita informação importante sobre modelo
transacional e garbage pode ser conseguido), porém toda documentação
está em inglês.

Para ajudar, também há muitos problemas (quase todos relacionados à
performance, por culpa do CommitRettaining) na dobradinha DBX +
Firebird, e aparentemente aqui está o seu problema.

Como sugestão, experimente isolar transações de consulta das transações
de manutenção (insert, deletes e updates). Sei que o DBX não possui
auto-commit pois um hard commit fecha o dataset. Muitos desenvolvedores,
diante desta informação, fazem uma especialização da query carregando os
dados de um select dinamicamente para uma "Memory Table" fechando
imediatamente a transação (e fazendo todos os sorts e buscas em
memória). Mas é claro que isto funciona para pequenos volumes de
informação, ou em parceiria com filtros extremamente eficases (limitando
o máximo de informação num grid em menos de 200 linhas)

Antes de migrar do SuperServer para o Classic Server, recomendo que você
procure entender bem as diferenças entre eles (e são muitas), não se
envergonhe de perguntar na lista sobre pontos que não estejam claros (e
a maioria das pessoas tem dificuldades ou dúvidas com o Classic). Comece
estudando o Firebird.Conf (há muita informação lá) pois, diferente do
SuperServer, o Classic exige o ajuste de alguns parâmetros para
funcionar a contento.

A mesma regra acima vale ao trocar o firebird 1.5 pelo 2.0 ou 2.1. Há
muitas coisas a considerar, e pode ser que a performance melhore muito,
mas há muitos relatos (todos com o 2.0) de degradação de performance
após a migração, pois tanto a construção do índice, quanto a adoção ou
não dos mesmos foi extensamente trabalhada entre estas versões. Devido
ao parâmetro do FB 2.1 para "relaxar" a ambiguidade de apelidos de
tabelas, acho mais seguro e melhor migrar do 1.5 diretamente para o FB
2.1, mas deve-se prestar a atenção sobre a existência de collate nas
tabelas de sistema, algo inexistente nas versões anteriores do FB.

Se os seus índices (todos eles, pks, fks, indexes) forem simples
(principalmente com um único campo, ou com poucos campos) você terá um
maior ganho de performance na migração, se os seus índices forem
complexos (mais de 3 campos) você poderá perder performance - mas aqui
depende de características do seu sistema, que só poderam ser definidas
após uma análise mais profunda.

Mas o FB 2.1, por ter sido lançado recentemente, não está 100% livre de
problemas... provavelmente teremos, ainda neste ano, um FB 2.1.1 com
algumas correções e otimizações.

Aproveitando, quanto à uma de suas perguntas, o GBAK não interfere no
resultado do GFIX -SWEEP (desde que não sejam feitos ao mesmo tempo).

Depois deste pequeno "livro", fico no aguardo de mais perguntas suas
aqui na lista...

PS: Todos nós temos muito o que aprender... Não raro vejo situações
novas aqui na lista que me instigam e rever os meus conceitos ou me
motivam a descobrir coisas novas. Espero poder aprender muito com este
seu problema... 


Sucesso

Eduardo Jedliczka


Em Seg, 2008-05-26 às 19:01 -0300, Maciel Soncini Bueno escreveu:
> Saudações Eduardo,
> 
> Primeiramente gostaria de agradecer o seu retorno e dizer que em hipótese
> alguma fiquei ofendido com seu e-mail.
> 
> Sobre contratar um desenvolvedor e um DBA ficará para uma próxima, vez que
> já temos desenvolvedores/DBA´s na equipe.
> 
> O sistema em questão roda em dezenas de clientes e, somente em um está
> apresentando os problemas mencionados por isso o questionamento para a
> lista.
> 
> Como a lista é aberta para dúvidas de usuários leigos, intermediários,
> avançados e, Firebird´s Mans que deve ser o seu caso, não me hesitei em
> montar o e-mail e enviar para a lista.
> 
> Assim sendo, vou pesquisar sobre o que escreveu e depois divulgar os
> resultados obtidos para a lista.
> 
> Tomo a liberdade de perguntar / comentar suas linhas:
> 
> "- suas transações estão extremamente longas (se é que está controlando
> isto);"
> - O que posso considerar como uma transação longa?
>   Tenho transactions no sistema dentre elas, transactions que podem ficar
> abertas por 05/10/15 minutos, por se tratar de um módulo de recepção de
> pacientes (clínicas, hospitais, centros de diagnósticos);
> "- Não está commitando os SELECTs (ou trabalha com CommitRetainnig com o
> controle feito pelo DBExpress);"
> Trabalho com o CommitRetainnig com o controle feito pelo DBExpress. Você
> pode me sugerir um link ou documentação para que eu possa melhorar ou
> entender melhor sobre isso?
> "- Não configurou o horário do SWEEP do banco (deixou automático a cada
> 20 mil transações);"
> Estava automático. Já desliguei o automático e coloquei para ser executado
> diariamente as 22h00. Neste horário não tem ninguém utilizando o sistema.
> Pergunto: Faz diferença executar o sweep antes ou depois do backup? O gbak
> está com a cláusula -G.
> "- Adotou o SuperServer numa máquina dual-core;"
> Pois é... Já tinha lido sobre o assunto, mas como no servidor antigo estava
> SuperServer, quando instalaram, fizeram igual. Já estou solicitando a troca
> de Super Server para Classic Server.
> Haverá muita vantagem se mudar para o Firebird 2.0?
> 
> "- entre outros..."
> Fale mais sobre entre outros....
> 
> "Mas isto é um ponto interessante.... muitas pessoas tem problemas de
> performance com o FireBird... pois acham que todos os bancos de dados
> são iguais, ou pior, acham que trabalhar com DBF, paradox ou tabelas em
> memória é igual a trabalhar com bancos relacionais..."
> 
> Eduardo, eu não disse isso. Já trabalhei com DBF, Paradox, Oracle, Sql
> Server e companhia. Sou fã do Firebird e trabalho com o mesmo desde 2002.
> 
> 
> "o Firebird, quando bem utilizado, tem uma performance impressionante (em
> rede local é claro... ainda tem um protocolo muito pesado e tagarela
> para ser utilizado diretamente via internet). Só que muitos fatores
> colaboram para a frustração dos desenvolvedores/utilizadores. É um banco
> pequeno, simples, leve, gratuito e fácil de administrar, e por esta
> razão, muitos não dão a devida importância. Não faze teste de stress,
> não monitoram índices e principalmente não procuram entender as regras
> transacionais ou o sistema de Versionning e Garbage Collection."
> 
> Como nunca tive problemas, nunca me preocupei mesmo, mas acho que há tempo
> de melhorar, não é memsmo?!
> 
> Se puder me indicar link´s, livros, etc..., que me esclareçam melhor sobre
> esses assuntos, agradeço.
> 
> Até mais,
> 
> Atenciosamente,
> 
> Maciel Soncini Bueno
> 2M SOLUTIONS
> 11-4438-6891 / 8555-8507
> maciel em 2msolutions.com.br
> www.2msolutions.com.br
> 
> 
> -----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, 26 de maio de 2008 14:30
> Para: FireBase
> Assunto: Re: [firebase-br] Lentidão
> 
> Para resolver seu problema, contrate um desenvolvedor e um DBA que saiba
> trabalhar com o FIREBIRD.
> 
> Se isto parecer muito radical, recomendo que reveja a forma como o
> aplicativo é escrito.... Posso estar enganado, mas os sintomas me levam
> ao seguinte diagnóstico:
> 
> - suas transações estão extremamente longas (se é que está controlando
> isto);
> - Não está commitando os SELECTs (ou trabalha com CommitRetainnig com o
> controle feito pelo DBExpress);
> - Não configurou o horário do SWEEP do banco (deixou automático a cada
> 20 mil transações);
> - Adotou o SuperServer numa máquina dual-core;
> - entre outros...
> 
> Mas isto é um ponto interessante.... muitas pessoas tem problemas de
> performance com o FireBird... pois acham que todos os bancos de dados
> são iguais, ou pior, acham que trabalhar com DBF, paradox ou tabelas em
> memória é igual a trabalhar com bancos relacionais...
> 
> o Firebird, quando bem utilizado, tem uma performance impressionante (em
> rede local é claro... ainda tem um protocolo muito pesado e tagarela
> para ser utilizado diretamente via internet). Só que muitos fatores
> colaboram para a frustração dos desenvolvedores/utilizadores. É um banco
> pequeno, simples, leve, gratuito e fácil de administrar, e por esta
> razão, muitos não dão a devida importância. Não faze teste de stress,
> não monitoram índices e principalmente não procuram entender as regras
> transacionais ou o sistema de Versionning e Garbage Collection.
> 
> Espero que não se sinta ofendido, e procure conhecer melhor o produto
> que pretende utilizar. Abraço!
> 
> Eduardo Jedliczka
> 
> 
> Em Seg, 2008-05-26 às 13:15 -0300, Maciel Soncini Bueno escreveu:
> > Cenário:
> > 
> > - Sistema desenvolvido em Delphi 7 com DBExpress.
> > - Banco de Dados Firebird 1.5 Super Sever.
> > - Sistema Operacional Linux Debian 2.6
> > - Processador Xeon Dual Core 2.66 GHZ
> > - Memória 2 GB RAM
> > - HD 250 GB SATA
> > - Placa de Rede 1 Gigabit com servidor ligado a porta de 1 gigabit no
> > switch.
> > 
> > Situação:
> > 
> > - Sistema muito lento.
> > - Retorno das querys muito lento.
> > - Reinicia o servidor e melhora, mas no dia seguinte está ruim novamente.
> > - Já reconstruí o banco e não melhorou.
> > 
> > O que posso fazer para melhorar?
> > Qual versão do Fireibird instalar?
> > Qual modalidade (Super Server ou Classic)?
> > Qual Page Size definir?
> > Se instalar Firebird 2.0 deve atualizar os client´s também?
> > Devo fazer alguma atualização no DBExpress se migrar para versão 2.0?
> > Deve mexer alguma coisa no setup da máquina (bios) para melhorar a
> > performance?
> > 
> > Já vi vários tópicos na lista sobre este assunto, mas se puderem me ajudar
> > agradeço.
> > 
> > Atenciosamente,
> > 
> > Maciel Soncini Bueno
> > 2M SOLUTIONS
> > 11-4438-6891 / 8555-8507
> > maciel em 2msolutions.com.br
> > www.2msolutions.com.br
> > 
> > 
> > 
> > ______________________________________________
> > 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
> 
> 
> ______________________________________________
> 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





Mais detalhes sobre a lista de discussão lista