Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

i have a Windows Server 2008 R2 (64bit) running a 64bit installation of Firebird in a 4GB phisical server.

After a while, the task manager show that all memory is used, but the sum of the memory of all process does not stack to the half of the memory. Unfortunally, it's start swapping.

Using RAMMAP, i can see that my entire database file is mapped into the memory. This only occours in windows server 2008 r2 and windows 7 64 bit. i can use firebird 32 or 64bit installations, doesn't matter.

How can i prevent this? Why this only occours in w2k8r2 and w7?

tks in advance


Aparently, this occours by the use of all memory by the file system cache. The microsoft documentations explain that this WAS a issue in windows xp, 2k3, vista and 2k8, but it was solved in 7 and 2k8r2. also adds that this issue is more common in 64bit hosts. (

there are some tools (DynCache, setcache and the Get/SetSystemFileCacheSize system calls from windows API) that allows me to fix a upper limit to the memory usage by the fscache, but the documentation argues that i should not do this in w2k8r2 because it will severely impact on the overall system performance. anyway, i tried, the performance remained the same shit and the use of the page file remained, although there is now more the 1gb of free memory.

share|improve this question
What do you mean by "it's start[ed] swapping" ? – mfinni Aug 17 '11 at 17:05
it's began to use the page file more than the actual database file – chesterman Aug 18 '11 at 13:11
What are you basing this on? What measurement are you seeing that gives you this idea? – mfinni Aug 18 '11 at 13:16
i'm measuring this with the perfmon utility, using the page files system counters – chesterman Aug 18 '11 at 13:20
up vote 1 down vote accepted

Well, problem solved, after all. it was a bit of windows tunning and a bit of firebird tunning.

On the windows side, the setcache really did the trick in keeping the size of the file system cache under control, even with microsoft saying that i would not need this. i've just added a schedule task to run in every boot.

but even after lowering the memory use, my firebird database was still using 12,5% of my dual-quad-core box: 100% of one core, and performance was terrible (30s to select all tuples from a table with just 10 tuples).

after some monitoring with sinática (, i've realize that my database was sweeping. so i disable automatic sweep and added another schedule task to do sweeps on a 2-day basis.

share|improve this answer

Here's an update on the issue (hopefully helpful):

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.

share|improve this answer

This issue can be mitigated by using the Microsoft DynCache tool. This workaround is applicable if you cannot change the FireBird server to a version that does not have the cache bug, for example when using software that requires a discontinued version, or such.

As DynCache is kind of difficult to acquire and properly set up, see instructions on how to use it here:

share|improve this answer

It looks like this will get you headed in the right direction -

share|improve this answer
tks for the tip, but that's not the case. – chesterman Aug 18 '11 at 13:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.