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
Comments
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) |
Commented by: Ann Harrison (awharrison) Is gbak itself consuming the memory, or is it the Firebird Server? |
Commented by: rudi feijo (rudibr) Classic, I will get the memory data tomorrow when there are very few users online. |
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? |
Commented by: rudi feijo (rudibr) I was looking at system wise (performance tab on task manager). 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. |
Modified by: Sean Leyne (seanleyne)status: Open [ 1 ] => Resolved [ 5 ] resolution: Duplicate [ 3 ] |
Commented by: Sean Leyne (seanleyne) Changed the summary to reflect the true nature/source of the issue |
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) |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
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. |
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. |
Modified by: @pavel-zotovQA Status: No test |
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.
The text was updated successfully, but these errors were encountered: