[firebase-br] Tamanho de cache

Seg Fev 9 15:22:03 -03 2015

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

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

Em 2 de fevereiro de 2015 14:44, Gladiston Santana
<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?
>>
>>
> ______________________________________________
> 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