[firebase-br] RES: RES: Ajuda com performance Firebird
Carlos H. Cantu
listas em warmboot.com.br
Sex Jan 8 12:19:22 -03 2016
Mesmo rodando sweep, se houver transações abertas há muito tempo, ele
não vai conseguir coletar todo o lixo.
[]s
Carlos H. Cantu
www.FireBase.com.br - www.firebirdnews.org
www.warmboot.com.br - blog.firebase.com.br
MSB> A controladora tem 01 gb de cache.
MSB> PERC H710P Adapter
MSB> 6Gb/s SAS
MSB> PCI-Express 2.0
MSB> 2x4 Internal
MSB> 1GB NV
MSB> Flash Backed Cache
MSB> 0,1,5,6,10,50,60
MSB> 32
MSB> Hardware RAID
MSB> Todas as madrugadas, antes de realizar o backup rodamos o comando abaixo:
MSB> gfix -sweep "bancodedados" -user SYSDBA -pas masterkey
MSB> A mais algo que poderia rodar antes do backup que por ventura poderia ajudar?
MSB>
MSB> Em 8 de janeiro de 2016 11:16, Carlos H. Cantu
MSB> <listas em warmboot.com.br> escreveu:
MSB> http://www.firebase.com.br/artigo.php?id=2718
MSB>
MSB> Mas não acredito que seja o caso do problema dele.
MSB>
MSB> []s
MSB> Carlos H. Cantu
MSB> www.FireBase.com.br - www.firebirdnews.org
MSB> www.warmboot.com.br - blog.firebase.com.br
MSB>
MAK>> Numa dessas isto te ajuda. Este e-mail é de 2013:
MSB>
MAK>> Reenviando o texto anexado:
MSB>
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:
MSB>
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."
MSB>
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.
MSB>
MAK>> Espero ter ajudado.
MSB>
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
MSB>
MAK>> Numa dessas isto te ajuda. Vide o e-mail anexo.
MSB>
MAK>> Att,
MAK>> Moacir
MSB>
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
MSB>
MAK>>
MSB>
MAK>> Bom Dia, posso estar falando besteira, mas será que não tem algum outro
MAK>> vazamento de memória no seu sistema?
MSB>
MAK>> pode não ser o FB e sim outras rotinas, por exemplo Objetos criados
MAK>> dinamicamente e sem destruição dos mesmos.
MSB>
MAK>> ou conexões abertas e não fechadas. etc.
MSB>
MAK>> ---
MSB>
MAK>> "ZOTTIS"
MAK>> Mauricio Zottis
MSB>
MAK>> Se quiser ir rápido, vá sozinho.
MAK>> Se quiser ir longe, vá em grupo.
MAK>> Provérbio Africano.
MSB>
MAK>> Em 08/01/2016 08:31, Jeronimo Cardoso Neto escreveu:
MSB>
>>> 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
MSB>
MSB>
MSB> ______________________________________________
MSB>
MSB> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
MSB> Para saber como gerenciar/excluir seu cadastro na lista, use:
MSB> http://www.firebase.com.br/fb/artigo.php?id=1107
MSB> Para consultar mensagens antigas:
MSB> http://www.firebase.com.br/pesquisa_lista.html
MSB>
Mais detalhes sobre a lista de discussão lista