[firebase-br] RES: RES: Ajuda com performance Firebird

[Carlos H. Cantu]

http://www.firebase.com.br/artigo.php?id=2718

Mas não acredito que seja o caso do problema dele.

[]s
Carlos H. Cantu
www.FireBase.com.br - www.firebirdnews.org
www.warmboot.com.br - blog.firebase.com.br

MAK> Numa dessas isto te ajuda.  Este e-mail é de 2013:

MAK> Reenviando o texto anexado:

MAK> A alguns dias, um cliente adquiriu um servidor DELL Power Edge (PET310), 6GB
MAK> RAM, dois HD SAS 500GB com uma controladora SAS 6iR, para ser utilizada como
MAK> servidor de um banco de dados Firebird.
MAK> Atualmente o banco de dados estava rodando em um Semprom com 256MB de
MAK> memória RAM (ou seja, possuia vaga lembrança), mesmo assim os relatórios
MAK> tinham uma performance muito boa, a espera pelos resultados era mínima,
MAK> nunca houve reclamação.
MAK> Quando passamos o banco de dados para o novo servidor, a expectativa de alta
MAK> performance foi enorme, mas a decepção foi maior ainda.
MAK> Os relatórios que antes a espera era de 3 a 4 segundos, passou para 12 a 15
MAK> segundos, outros processos que demoravam um pouco, passou a demorar uma
MAK> eternidade.
MAK> Ficamos loucos com isso, começamos a depurar o sistema atras de selects mau
MAK> escritos, etc., mas era uma caso que a principio não tinha explicação, pois
MAK> o mesmo banco de dados quando copiado de volta para qualquer micro
MAK> xinguiling dava de 10 a zero do servidor DELL.
MAK> Isso durou uma semana até que conseguimos falar com um Analista de
MAK> Servidores da DELL que nós escreveu o seguinte:

MAK> "O servidor PET310 de TAG: DGD6QM1, está equipado com uma controladora SAS
MAK> 6iR, essa controladora não possui cache e dessa forma não oferece uma grande
MAK> performance relacionada a leitura e escrita em disco.
MAK> Para “rodar” Banco de Dados é recomendado uma controladora com cache e
MAK> utilizar Raid 10, o servidor em questão está equipado com Raid 10 e não
MAK> temos cache."

MAK> E por telefone o mesmo analista disse que qualquer micro pessoal possui mais
MAK> cache que a configuração adquirida.
MAK> A sugestão foi trocar a controladora por uma com mais cache, o cliente
MAK> adquiriu uma com 512 de cache, e o resultado: qualquer coisa que coloque
MAK> para rodar lá vira um foguete, estou até com inveja, pois tenho um servidor
MAK> IBM Xeon que agora perde feio para o DELL.

MAK> Espero ter ajudado.

MAK> -----Mensagem original-----
MAK> De: lista [mailto:lista-bounces em firebase.com.br] Em nome de Moacir Antonio
MAK> Kuhn
MAK> Enviada em: sexta-feira, 8 de janeiro de 2016 10:15
MAK> Para: 'FireBase'
MAK> Assunto: [firebase-br] RES: Ajuda com performance Firebird

MAK> Numa dessas isto te ajuda.  Vide o e-mail anexo.

MAK> Att,
MAK> Moacir 

MAK> -----Mensagem original-----
MAK> De: lista [mailto:lista-bounces em firebase.com.br] Em nome de Zottis Enviada
MAK> em: sexta-feira, 8 de janeiro de 2016 08:41
MAK> Para: FireBase
MAK> Assunto: Re: [firebase-br] Ajuda com performance Firebird

MAK>  

MAK> Bom Dia, posso estar falando besteira, mas será que não tem algum outro
MAK> vazamento de memória no seu sistema? 

MAK> pode não ser o FB e sim outras rotinas, por exemplo Objetos criados
MAK> dinamicamente e sem destruição dos mesmos. 

MAK> ou conexões abertas e não fechadas. etc. 

MAK> ---

MAK>  "ZOTTIS"
MAK> Mauricio Zottis

MAK> Se quiser ir rápido, vá sozinho.
MAK> Se quiser ir longe, vá em grupo.
MAK> Provérbio Africano.

MAK> Em 08/01/2016 08:31, Jeronimo Cardoso Neto escreveu: 

>> Depois de 2 anos, controle
>> transacional, acho q não. Eu investigaria o hardware primeiro.
>> 
>> Em 8 de janeiro de 2016 08:23, Kelver Merlotti <kmerlotti em gmail.com>
>> escreveu:
>> Pelo que você descreveu, arriscaria dizer que é problema no controle 
>> transacional! Você disse: "O sistema possui algumas rotinas com 
>> transaction.", mas pro Firebird TUDO está em transação! Sei que é 
>> fácil falar e difícil de fazer, mas revisar o controle transacional do 
>> seu sistema me parece uma alternativa válida (pelos sintomas e pelo 
>> que você descreveu). Abraços, *Kelver Merlotti* Coordenador Editorial 
>> da Active Delphi Twitter: http://www.twitter.com/kmerlotti [1]
>> 2016-01-07 23:41 GMT-02:00 Maciel Soncini Bueno 
>> <maciel em 2msolutions.com.br : Saudações, Trabalho com Firebird a muitos 
>> anos, e resolvi teoricamente todo e qualquer problema de performance 
>> com meus sistemas quando adotamos a versão 2.5 64 bits Super Classic 
>> Server. Tenho um cliente em especial, o de maior movimento, que tenho 
>> tido problemas de performances. Gostaria da opinião e ajuda dos amigos 
>> da lista. Nos primeiros problemas de performance, trocamos de servidor 
>> e, a alguns meses, depois de uns 02
MAK> (dois) anos, venho enfrentando problemas de performance, mas não vejo o
MAK> servidor consumir mais que 50% de cpu e nem 10 GB de memória, considerando o
MAK> servidor como um todo. Esta servidor foi o quarto, em 10 anos no cliente.
MAK> Configuração do Servidor: Dell Server PET 620 Intel Xeon CPU ES-2630 v2 2.60
MAK> GHZ (02 processadores) Memória RAM de 64 GB Windows Server 2012 64 BITS
MAK> Disco Rígido de 02 TB Firebird 2.5 (versão novembro 2015) Super Classic
MAK> Server Sistema em Delphi7 DBExpress (DLL Devart) O sistema possui algumas
MAK> rotinas com transaction. O banco atualmente está com 200 GB. Já chegou a ter
MAK> 250 GB, mas excluímos alguns anos de movimento a título de tentar resolver.
MAK> De uma forma sucinta, o sistema roda bem, e em torno de 02 (duas) semanas,
MAK> começa a ter problemas de performance. Após realizarmos um backup / restore,
MAK> o sistema volta a ficar com uma performance boa e, ficamos nessa situação.
MAK> Sweep está desligado e executamos toda noite. Pages está 75 Bufffers 300 KB
MAK> A alguns meses o Pages estava em 225. Fui aumentando com o tempo conforme
MAK> foram me reportando problemas de performance, mas depois um backup / restore
MAK> deixei no padrão. Antigamente, no servidores anteriores, verificávamos o
MAK> momento de trocar o servidor quando a CPU começar a ficar acima de 90% e não
MAK> baixava mais. A memória em torno "quase" 100% ocupada e não baixava mais.
MAK> Neste servidor, o processador não passa de 45%. As vezes notamos,
MAK> principalmente durante as reclamações de performance, que o consumo de CPU
MAK> do banco está 30%, por exemplo, e não muda, não desce. A memória está em
MAK> torno de 08 GB. Teoricamente o servidor está tranquilo, mas parece que o
MAK> Firebird não consegue usufruir todo potencial do servidor. O disco é rápido
MAK> e a controladora fora de série, com bastante cache de disco. Neste cenário,
MAK> não tenho como sugerir outro servidor. Ficar nessa vida de backup / restore,
MAK> ninguém merece. O processo leva em torno de 04 (quatro) horas e só pode ser
MAK> realizado após 22hs00. Tenho em torno de 125 conexões simultâneas no horário
MAK> de pico, que é das 09hs00 - 14hs00. Neste período ocorre as reclamações e só
MAK> backup / restore para sossegarem. Pela experiência do grupo, o que me
MAK> sugerem? Jà começamos a cogitar outro banco de dados, mas como fui sempre um
MAK> forte defensor do Firebird, o pessoal sequer acredita que devemos trocar.
MAK> Acham que tenho um cartola na manga e conseguirei honrar o nome do Firebird,
MAK> mas sinceramente, está difícil, rsss. Estou aberto a sugestões. Maciel