Issue Details (XML | Word | Printable)

Key: CORE-3791
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Dmitry Yemanov
Reporter: Nickolay Samofatov
Votes: 0
Watchers: 8
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Performance degrades when actively working with databases bigger than the available RAM amount

Created: 18/Mar/12 08:20 AM   Updated: 02/Jul/13 10:14 AM
Component/s: Engine
Affects Version/s: 2.1.0, 2.1.1, 2.0.5, 2.1.2, 2.1.3, 3.0 Initial, 2.0.6, 2.5.0, 2.1.4, 2.5.1
Fix Version/s: 2.1.5, 2.5.2, 3.0 Alpha 1

Time Tracking:
Not Specified

Environment:
Firebird (both 32-bit and 64-bit) on Windows 64-bit hosts.
Windows 2008 and Windows 7 are known to be affected, Windows 2003 R2 is suspected.
Issue Links:
Relate
 

Planning Status: Unspecified


 Description  « Hide
With the random file access requested, the Windows file-system cache is growing so that it could fit all the accessed pages. If the whole database is being accessed (e.g. by the backup process or just very random I/O pattern) and its size is larger than either the configured FileSystemCacheSize setting or the available RAM size, the swapping occurs. In the worst case it leads to the shrinked working set of the Firebird server itself but sometimes even Windows itself can go out of the available physical memory and crash.

Confirmation by Microsoft:
http://support.microsoft.com/kb/2549369


 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 27/Mar/12 08:45 AM
FILE_FLAG_RANDOM_ACCESS was removed. The default value for FileSystemCacheSize config option was set to zero (limit is disabled).

Jesus Angel Garcia Zarco added a comment - 27/Mar/12 09:57 AM
Is this tested in a real enviroment? Has been tested the prior situation?

I have a windows 2008 server standard that has this problem, but setting by os max cache memory did solve it. The test i did were for a day with a 32 Gb database, not several days working.

Do you want that I test it?

Dmitry Yemanov added a comment - 27/Mar/12 10:06 AM - edited
Your testing would be much appreciated. The fix will be available in the tomorrow's snapshot builds.
Also, read here for more info:
http://dyemanov.blogspot.com/2012/03/firebird-vs-windows-file-system-caching.html

Jesus Angel Garcia Zarco added a comment - 29/Mar/12 03:05 PM
I have tested it with one 20Gb database and windows 2008 R2 64 enterprise with 4 Gb RAM. Of course I have read before your link, and after read it I suppouse that my test was not neccesary, but i have done it.

Before update Firebird 2.5.2 to the latest snapshot, doing a simple bacukp, the server freeze after 3 Gb backup.

Once updated firebird to latest snapshot, the backup has been done without problem, and no more of 3 Gb RAM used during the process.

Dmitry Yemanov added a comment - 29/Mar/12 04:14 PM
Thanks for your testing, it does confirm the other results we have.

vander clock stephane added a comment - 09/Nov/12 12:11 PM
is it not better to simply delete this old option FileSystemCacheSize ? what the purpose to keep it ?

Sean Leyne added a comment - 09/Nov/12 04:50 PM
Stephane,

The source of the problem is actually the way that MS implemented cache logic for files opened with FILE_FLAG_RANDOM_ACCESS attribute. The fix was rather simple, remove attribute from the file open operations.

Sylvain P added a comment - 28/Jun/13 10:20 AM
I have this exact problem with Firebird 2.5.2 x64 on Windows 2008 R2 Datacenter. With a 15GB database on a server with 4GB RAM, all memory is quickly used by the windows filsystem cache as shown by RAMMap. Performances become very bad.
The same configuration on Windows 2003 R2 x86 has no problem : only about 1GB of RAM used and queries are faster.

Firebird never crash but performance is very bad in comparison of the Win2003 configuration.

Is this bug fully fixed on 2.5.2 ?
Is there a workaroud to this problem ?

Dmitry Yemanov added a comment - 02/Jul/13 08:24 AM
Please elaborate - do you experience this problem only with v2.5.2 (while prior versions work better) or you have the problem with any FB version?

Sylvain P added a comment - 02/Jul/13 10:14 AM
We have no problem with Firebird 1.5.6 Superserver on Win 2003 32bits.
We have this problem with Firebird 1.5.6 Superserver and Firebird 2.5.2 Superserver (never tested with anoter 2.x version) in 32bits and 64bits on Windows 2008 R2.

Since the last message, we added 4GB more memory on the server, so it's a 8GB RAM, with Firebird 2.5.2 x64 on Win 2008 R2.

Yesterday morning, only 2.1 GB of the 8GB was used on the server. fbserver.exe used 350 MB. Performance was good.

Then, at 11:00 about, 6.5GB were used. fbserver.exe used only 380MB. Performance became very bad.
I run MS RAMMap and see that 3.5 GB of the database file was in the filesystem cache, and 1GB of a fb_sort_xxx file (in c:\windows\temp) was in the filesystem cache too.

At 18:00, 7.6GB of the 8GB memomy were used. fbserver.exe still used only 380MB.
I run RAMMap and see that the database file was not in the filesystem cache, neither the temp file. So there was about 6GB of memory used without explanation. (The sum of all memory used by processes was about 2GB). Maybe a RAMMap bug too ?

I decided to stop the firebird engine and the 6GB were immediately freed. Only 2.2GB used of the 8GB.
So Firebird used this memory but I don't really know how.

I started FB again and the memory is OK, like at morning.

Today, same scenario : It's 12:00 and about 4GB is used. (only 2.5 this morning).

We have another server : FB 1.5.2 32bits, Windows 2003 R2 x86. No "ghost" memory used and perfromances is far better.