Alta utilização de memória com o firebird + windows server 2008 r2

2

Eu tenho um Windows Server 2008 R2 (64 bits) executando uma instalação de 64 bits do Firebird 2.1.4.18393_0 em um servidor físico de 4GB.

Depois de um tempo, o gerenciador de tarefas mostra que toda a memória é usada, mas a soma da memória de todo o processo não é acumulada na metade da memória. Infelizmente, é começar a trocar.

Usando RAMMAP, eu posso ver que todo o meu arquivo de banco de dados é mapeado na memória. Isso só ocorre no windows server 2008 r2 e no windows 7 64 bit. posso usar instalações firebird 32 ou 64bit, não importa.

Como posso evitar isso? Por que isso ocorre apenas em w2k8r2 e w7?

tks adiantado

** ATUALIZAÇÃO

Aparentemente, isso ocorre pelo uso de toda a memória pelo cache do sistema de arquivos. As documentações da microsoft explicam que este era um problema no windows xp, 2k3, vista e 2k8, mas foi resolvido em 7 e 2k8r2. também adiciona que esse problema é mais comum em hosts de 64 bits. ( link )

existem algumas ferramentas (DynCache, setcache e as chamadas do sistema Get / SetSystemFileCacheSize da API do Windows) que me permitem fixar um limite superior ao uso da memória pelo fscache, mas a documentação argumenta que eu não deveria fazer isso no w2k8r2 porque isso afetará severamente o desempenho geral do sistema. De qualquer forma, eu tentei, o desempenho permaneceu a mesma merda e o uso do arquivo de paginação permaneceu, embora haja agora mais 1GB de memória livre.

    
por chesterman 17.08.2011 / 19:03

4 respostas

1

Bem, problema resolvido, afinal. foi um pouco de tunning do Windows e um pouco de tunning firebird.

No lado do Windows, o setcache realmente fez o truque em manter o tamanho do cache do sistema de arquivos sob controle, mesmo com a microsoft dizendo que eu não precisaria disso. Acabei de adicionar uma tarefa de agendamento para executar em cada inicialização.

mas mesmo depois de diminuir o uso da memória, meu banco de dados ainda usava 12,5% da minha caixa dual-core: 100% de um núcleo, e o desempenho era terrível (30s para selecionar todas as tuplas de uma tabela com apenas 10 tuplas).

depois de algum monitoramento com a sinática (www.sinatica.com), percebi que meu banco de dados estava varrendo. Por isso, desativei a varredura automática e adicionei outra tarefa de agendamento para fazer varreduras em uma base de dois dias.

    
por 19.08.2011 / 02:11
1

Aqui está uma atualização sobre o problema (esperamos que seja útil):

link

So the only effective solution seems to disable the random access request (i.e. remove the FILE_FLAG_RANDOM_ACCESS flag) from the Windows API calls used to create/open the files. Moreover, in this case the file-system cache size limit should not be actual anymore, as Windows won't be expanding the cache out of the reasonable boundaries.

...

this solution has been committed into Firebird 2.1.5, Firebird 2.5.2 and Firebird 3.0 branches.

    
por 28.03.2012 / 13:02
1

Esse problema pode ser atenuado usando a ferramenta Microsoft DynCache. Esta solução alternativa é aplicável se você não puder alterar o servidor FireBird para uma versão que não possua o bug de cache, por exemplo, ao usar software que exija uma versão descontinuada ou algo semelhante.

Como o DynCache é difícil de adquirir e configurar corretamente, consulte as instruções sobre como usá-lo aqui: link

    
por 05.06.2014 / 13:01
0

Parece que isso vai levá-lo na direção certa - link .

    
por 18.08.2011 / 11:17