Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

After gbak -b system memory will not be released [CORE3699] #4047

Closed
firebird-automations opened this issue Dec 15, 2011 · 9 comments
Closed

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Gerhard Knapp (prometheus)

Votes: 1

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.

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

What memory counter do you look at ?
What process is crashed "without memory" ?

@firebird-automations
Copy link
Collaborator Author

Commented by: Gerhard Knapp (prometheus)

>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.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

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?

@firebird-automations
Copy link
Collaborator Author

Commented by: Gerhard Knapp (prometheus)

>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).

@firebird-automations
Copy link
Collaborator Author

Commented by: Gerhard Knapp (prometheus_gk)

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.

@firebird-automations
Copy link
Collaborator Author

Modified by: Sean Leyne (seanleyne)

description: 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.

=>

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.

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

Gerhard,

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.

@asfernandes
Copy link
Member

Do we have a reason to maintain this issue opened?

@hvlad
Copy link
Member

hvlad commented Oct 19, 2022

I see no such a reason

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants