Issue Details (XML | Word | Printable)

Key: CORE-3699
Type: Bug Bug
Status: Open Open
Priority: Critical Critical
Assignee: Unassigned
Reporter: Gerhard Knapp
Votes: 1
Watchers: 6

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

After gbak -b system memory will not be released

Created: 15/Dec/11 03:06 AM   Updated: 12/Nov/14 07:11 PM
Component/s: GBAK
Affects Version/s: 2.5.1
Fix Version/s: None

Environment: Windows 7 x64, Firebird 2.5.1 x64 SuperClassic, 8 GB Ram, Intel QuadCore CPU, Intel SSD

 Description  « Hide
Database size around 4 GB, after each backup the memory usage increases 2-3 GB, till server crash without memory ..

Only if i stop the Firebird service after the gbak -b , the memory will be released.

To change the default FileSystemCacheSize = 30 -> 10 doens't fix or alter the problem

Only FileSystemCacheThreshold = 0 fix the problem, BUT this is a bad possiblity, because then the Firebird server has slow performance.

in 24/7 production this is a big bug. I cannot do a backup all 6 hours as used before, had to change to one in the night, and stop/start Firebird Service.

No other process i know has this memory eating issue. And its not good to say, this is a windows problem, because if i stop firebird service the associated file cache also
is released. Therefore i think its an issue in the pair: Firebird Service and GBAK Utility.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Vlad Khorsun added a comment - 15/Dec/11 09:29 AM
What memory counter do you look at ?
What process is crashed "without memory" ?

Gerhard Knapp added a comment - 15/Dec/11 10:07 AM - edited
>What memory counter do you look at ?
Taskmanager, Performance, main memory usage if i look in the Process-MemUsage table i cannot find any process that has assigned this huge memory, also not fb_inet_server.exe

BUT: if i stop the Firebird service, the huge memory is freed.

>What process is crashed "without memory" ?
It is not a single process that crashes, the whole windows system comes instable, if i reach after the second backup more as 8 GB Memory usage.

A windows alert also comes: Out of memory
then a reboot of the computer is necessary.

I did some heavy memory tests, pyhsical memory is okay.

On all the Firebird versions before (beginning from Firebird 1.0) i never had such an issue.

Dmitry Yemanov added a comment - 15/Dec/11 10:13 AM
What Windows versions did you use with prior FB versions? I bet it wasn't Win7 x64. Also, is there anything unusual in firebird.log?

Gerhard Knapp added a comment - 15/Dec/11 10:44 AM - edited
>What Windows versions did you use with prior FB versions? I bet it wasn't Win7 x64. Also, is there anything unusual in firebird.log?

Lol, as i changed to Firebird (from ms sql and other databases like informix) i think 10 years ago, there was no win7 x64 :)

And i am a Firebird FAN all the time, and i have deep respect from the firebird developers. I am so happy SuperClassic 2.5 is here, so i can use multi cpu and multithreading. It was time ...

And x64 is also a big advantage because of the 32 bit memory limit.

I cannot find some unusal log entries, the normal one i have since years like
HALL8000 Wed Dec 14 19:21:15 2011
INET/inet_error: read errno = 10054
but only few.

I know, its often hard to find a bug, that not happens all the time, and there are so many different installations and hardware.

But i try to help what i can to find this.

It seems it happens only if the database is bigger as ~4B, i have 3 databases on this server running.

DB_A = 1.9 GB filesize, Page Size = 16384, Buffers (pages = 75, KB = 1200) (0 or 1 users attached)
DB_B = 5.8 GB filesize, Page Size = 4096, Buffers (pages = 4096, KB = 16384) (multi users attached)
DB_C = 4.9 GB filesize, Page Size = 4096, Buffers (pages = 4096, KB = 16384) (multi users attached)

GBAK on DB_A : used memory after gbak will be freed.
GBAK on DB_B: used memory after gbak not freed.

DB_B is the main high updated and used database, and i only backup this normally all 6 hours.

I let firebird.conf standard settings, because i found no documentation that describes the SuperClassic parameter aspects (only Classic or Superserver notes i found).

Gerhard Knapp added a comment - 12/Nov/14 12:42 PM
Now (2014-11) this bug exists also on Firebird 2.5.2 and Firebird 2.5.3, on Windows 7 64 bit and Windows 8 64 bit.
It happens on each computer! Its a high risc bug! because it causes server crash with time.

Sean Leyne added a comment - 12/Nov/14 07:11 PM

To see what process/purpose is consuming all RAM you could try to use the SysInternals RamMap utility. It would show the amount of RAM used broken down by Usage Type, as well as the amount of cache allocated to specific files.

BTW, the "bug" is not really unique to Firebird, it is the result of a issue with Window cache management under x64 OS's (as far back as Win2003 Server). There are a number of post on workarounds which are available online.