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

Windows cache usage grows during gbak (was: gbak consuming as much memory as there is available) [CORE4106] #4434

Closed
firebird-automations opened this issue May 24, 2013 · 14 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: rudi feijo (rudibr)

Is related to CORE3791

Running gbak will cause the process to continuously use more memory.
Type of data, db scheme, or any other variable like that doesnt seem to affect this behaviour.

As long as its running, it will consume more and more memory, as if memory was leaking.

Ive tried to gbak with -g and without -g, and the results are the same.

This behaviour is making it impossible for us to backup large dbs, since eventually their gbak will consume all memory available and the server stops responding properly to requests.

Ive been using firebird for about 6 years and never had that problem before. We just switched datacenters, from an identically configured machine, which is why this boggles me so much.

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

Please confirm the engine version (Classic, SuperClassic) which you have deployed, as well as the cache settings in the Firebird.config file.

Further, please confirm which memory block is being consumed? (Working Set, Private Memory, Commit Size, Paged Pool and/or Non-paged Pool)

@firebird-automations
Copy link
Collaborator Author

Commented by: Ann Harrison (awharrison)

Is gbak itself consuming the memory, or is it the Firebird Server?

@firebird-automations
Copy link
Collaborator Author

Commented by: rudi feijo (rudibr)

Classic,
Its the firebird server process started by gbak, not gbak itself.

I will get the memory data tomorrow when there are very few users online.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

What kind of memory is being consumed? Do you look at the per process (fb_inet_server) memory counters or system wise memory counters?

@firebird-automations
Copy link
Collaborator Author

Commented by: rudi feijo (rudibr)

I was looking at system wise (performance tab on task manager).
Even though the fb_inet_server.exe process memory usage grow up and never releases memory, it doesnt account for the number I see on memory usage system wide,
for example, the fb_inet_server goes from 40k to 60k (working set) during this operation, and the system memory goes from 2gb to 8gb usage.
The other memory indicators (Private Memory, Commit Size, Paged Pool and/or Non-paged Pool) are also not indicating a big usage private was about 50k, and the pools a few hundred k's.

There was no other proccess using memory that would account to that number as well. I tried to "add up" memory usage of all processes started a few times, but it didnt account for the total memory being actually used.

Killing the 60k fb_inet_server process would free up all 4~5 gigs of memory.

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

So it's the Windows filesystem cache that's growing, not the Firebird's memory. It sounds familiar (see CORE3791), although it's expected to be addressed in v2.1.5.

@firebird-automations
Copy link
Collaborator Author

Modified by: Sean Leyne (seanleyne)

Link: This issue is related to CORE3791 [ CORE3791 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: Sean Leyne (seanleyne)

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Duplicate [ 3 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

Changed the summary to reflect the true nature/source of the issue

@firebird-automations
Copy link
Collaborator Author

Modified by: Sean Leyne (seanleyne)

summary: gbak consuming as much memory as there is available => Windows cache usage grows during gbak (was: gbak consuming as much memory as there is available)

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: rudi feijo (rudibr)

We upgraded to 2.1.6 and the problem went away, might indicate it was the same problem as CORE3791.
Thank you for the support.

@firebird-automations
Copy link
Collaborator Author

Commented by: Jesus Angel Garcia Zarco (cointec)

I understand your problem, but what I don't understand is that a problem that is solved in versión 2.1.5 still affect versión 2.1.5 update 1 and appears to be solved in versión 2.1.6.

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

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

1 participant