Issue Details (XML | Word | Printable)

Key: CORE-4106
Type: Bug Bug
Status: Closed Closed
Resolution: Duplicate
Priority: Major Major
Assignee: Unassigned
Reporter: rudi feijo
Votes: 0
Watchers: 3
Operations

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

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

Created: 24/May/13 06:21 PM   Updated: 18/Oct/16 06:03 PM
Component/s: GBAK
Affects Version/s: 2.1.5 Update 1
Fix Version/s: None

Environment: win2008 r2 datacenter 64bit, mounted on a xeon 2.6g, 8 cores, 8gb ram
Issue Links:
Relate
 

QA Status: No test


 Description  « Hide
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.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Sean Leyne added a comment - 24/May/13 06:40 PM - edited
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)

Ann Harrison added a comment - 24/May/13 07:52 PM
Is gbak itself consuming the memory, or is it the Firebird Server?

rudi feijo added a comment - 24/May/13 08:21 PM
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.

Dmitry Yemanov added a comment - 25/May/13 02:43 AM
What kind of memory is being consumed? Do you look at the per process (fb_inet_server) memory counters or system wise memory counters?

rudi feijo added a comment - 27/May/13 02:35 PM
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.

Dmitry Yemanov added a comment - 27/May/13 02:52 PM
So it's the Windows filesystem cache that's growing, not the Firebird's memory. It sounds familiar (see CORE-3791), although it's expected to be addressed in v2.1.5.

Sean Leyne added a comment - 27/May/13 05:10 PM
Changed the summary to reflect the true nature/source of the issue

rudi feijo added a comment - 31/May/13 02:49 PM
We upgraded to 2.1.6 and the problem went away, might indicate it was the same problem as CORE-3791.
Thank you for the support.

Jesus Angel Garcia Zarco added a comment - 31/May/13 06:35 PM
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.