[firebase-br] Tamanho de cache

[Carlos H. Cantu]

Achar que aumentando absurdamente o tamanho do cache do Firebird
estará automaticamente ganhando performance é um erro comum. Na verdade,
o efeito muitas vezes é o inverso.

Lembre-se também que o sistema operacional já faz cache de disco,
portanto, você tem um duplo cache.

Configure o cache do Firebird com um valor razoavel e deixe o resto da
memória livre pro sistema operacional usar com cache de disco. Se
estiver usando o SuperServer, experimente configurar como 10.000

Sugiro também a leitura desses slides:
http://pt.slideshare.net/ibsurgeon/resolving-firebird-performance-problems


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

RFFeA> Amigos, primeiramente, quero agradecer todas as respostas que recebi.
RFFeA> Vou relatar o que ocorreu aqui.
RFFeA> Esse fim de semana, aumentei MUITO o número de página do servidor.
RFFeA> Das 2048 que eu tinha para 65.536.
RFFeA> Com isso, fiquei com um tamanho de cache de 512Mb.
RFFeA> Achei que era um bom tamanho, visto que estava com memória "sobrando".
RFFeA> Pois bem, hoje cedo, primeiro dia útil após a mudança, o sistema ficou
RFFeA> EXTREMAMENTE lento.
RFFeA> Estava impossível de trabalhar.
RFFeA> O estranho é que o servidor não chegou a utilizar toda a RAM.
RFFeA> Bem, precisei desfazer o que fiz. Mudei novamente o número de página,
RFFeA> agora para 4096 e estou com o dobro do que tinha inicialmente.
RFFeA> Com isso o desempenho do banco voltou ao normal.
RFFeA> Sei que errei em aumentar tanto o tamanho do cache sem testes mais
RFFeA> elaborados, mas gostaria de entender o motivo de um cache muito grande
RFFeA> ser ruim para o desempenho.
RFFeA> Alguém poderia me ajudar?
RFFeA> Em tempo, vou fazer aumentos progressivos e tentar achar um bom parâmetro.
RFFeA> Também estou estudando a mudança da versão do SuperServer para Classic
RFFeA> uma vez que o servidor tem 4 núcleos.
RFFeA> Porém, nessa versão, sei que preciso ser cuidadoso com o tamanho do
RFFeA> cache pois ele será criado para cada conexão.
RFFeA> No meu caso atual, eu teria um cache de 32Mb para cada estação, correto?
RFFeA> Desde já agradeço pela ajuda.




RFFeA> --
RFFeA> Rafael Cardoso Stella
RFFeA> Gerente Financeiro
RFFeA> FAV Comércio de Ferro e Aço LTDA
RFFeA> Fone: (15) 3229-5050 - (11) 4523-5833 - FAX: (15) 3229-5055
RFFeA> rafael.sorocaba em favcomercial.com.br
RFFeA> http://www.favcomercial.com.br


RFFeA> Em 2 de fevereiro de 2015 14:44, Gladiston Santana
RFFeA> <gladiston em vidy.com.br> escreveu:
>> O tamanho de página de dados influencia o tamanho do cache do FB com
>> certeza, mas recomenda-se ter o tamanho multiplo do cluster do seu sistema
>> de arquivos. Ex:
>> # tune2fs -l /dev/sda1 | grep -i 'block size'
>> Block size:               4096
>>
>> No exemplo acima, meu disco usa um cluster de 4k, então os tamanhos de
>> páginas recomendados para usar são:4k, 8k, 12k, 16k. O tamanho de página
>> está muito relacionado aos indices e ao tamanho de cache de páginas, pois o
>> FB cacheia páginas inteiras. Um cache de 2.000 páginas
>> (parametro DefaultDbCachePage) de 16k, siginifica 16k*2000. Se forem 50
>> estações simultanea, então multiplique por 50. Isso será uma estimativa de
>> consumo de RAM razoável que será usada pelo FB.
>>
>> Talvez voce não precise ficar quebrando a cabeça com contas, aumente o
>> tamanho da página (e/ou DefaultDbCachePages)  e monitore o consumo de ram
>> deste servidor com todos conectados, tente com páginas de 8k/12k/16k e
>> aquele que alcançar resultados melhores, mantenha.
>>
>> Deixe uma sobra de RAM e lembre-se que ao usar 'free -h' o que você ver em
>> buffers/cache é também memoria livre do sistema, já que em ambiente linux,
>> memória não usada acaba virando cache.
>>
>> Dê ouvido ao que os colegas disseram,  a edição classic é mais conveniente
>> em servidores com vários nucleos, isso não muda a compatibilidade com o seu
>> aplicativo, mas tome cuidado em não mexer no arquivo de cofiguração
>> (firebird.conf,aliases.conf) e no security2.fdb - é um sistema de terceiros
>> e você não sabe se os camaradas fizeram ajustes neles.
>>
>> É minha opinião e outros discordam, mas para mim, restore só é indicado se
>> algum problema ocorrer. Ao fazer restore apenas por fazer, você mata
>> estatisticas armazenadas internamente que poderiam melhorar a performance
>> com o passar do tempo.
>>
>> inte+
>>
>>
>>
>> Em 30 de janeiro de 2015 12:04, Rafael - FAV Ferro e Aço <
>> rafael em favcomercial.com.br> escreveu:
>>
>>> Robson e Gladiston, muito obrigado.
>>> Vamos lá.
>>> Quanto à versão, eu não tenho muito controle, pois a base foi
>>> desenvolvida pela empresa que fez o sistema.
>>> Eu já solicitei a atualização para essa versão, mas eles estão
>>> estudando ainda se não daria nenhum problema.
>>> É sabido também (por mim e por eles) que o sistema mantém transações
>>> abertas por muito tempo.
>>> Acontece que a empresa criadora do sistema está desenvolvendo uma nova
>>> versão (vão mudar a estrutura de cliente/servidor para web) e novas
>>> melhorias nessa versão estão suspensas, a não ser que sejam erros ou
>>> problemas críticos.
>>> Eu acho que esse problema de performance é crítico, mas enfim, não
>>> posso ficar dependendo somente deles, devo fazer tudo o que estiver a
>>> minha disposição.
>>> O backup é diário, mas o restore é semanal. Posso estudar pra mudar isso.
>>> Para eu aumentar o cache, priorizo o aumento do tamanho da página ou o
>>> número de páginas?