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

Firebird memory not released (Using superserver) [CORE3533] #3890

Closed
firebird-issue-importer opened this issue Jun 22, 2011 · 14 comments
Closed

Firebird memory not released (Using superserver) [CORE3533] #3890

firebird-issue-importer opened this issue Jun 22, 2011 · 14 comments

Comments

@firebird-issue-importer

Submitted by: Jesus Angel Garcia Zarco (cointec)

Attachments:
fbmemory.rar

Votes: 1

I'm using Firebird 2.5.1.26292 Superserver. The server is running for two weeks and the memory consumption increase daily, but not decrease. I have tested in other enviroment, and all the memory is freed only when all users are disconnected. For know, using Process Explorer from sysinternals, 1326148K of private bytes and 1145716K of Working set, but everyday is increasing between 50 and 100Mb.

After two weeks working, today i have started to have this problem (Operating system call _beginthreadex failed. Error code 8), and i have read that is a problem of memory with server that can not allocate more than 2 Gb. This is because day by day the memory consumption increase, more and more.

If i disconnect all users, fbserver only uses 8 Mb RAM, all memory is released right and start by a memory consumption low, between 200 and 300 Mb, but day by day it increses the momory usage.

I have sent emails attached, with several selects from mon$*, but Alexander Peshkov, can't help anymore because he work only with posix builds. This database structure is used in Firebird 1.0 and Interbase 7-2009 for years without problem.

I only use in my app one UDF and this is the code:

unit UDFMath;

interface

function UDF_power( var Base, Exponent: Double ): double; cdecl; export;
function UDF_sqrt( var Value: double ): double; cdecl; export;

implementation

uses Math;

function UDF_power(var Base, Exponent: Double): double; cdecl;
begin
try
Result := power( Base, Exponent );
except
Result := 0;
end;
end;

function UDF_sqrt( var Value: double ): double; cdecl;
begin
try
Result := sqrt( Value );
except
Result := 0;
end;
end;

initialization
IsMultiThread := True;

end.

Commits: 86adbc3

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jun 22, 2011

Commented by: Jesus Angel Garcia Zarco (cointec)

I have executed this queryes and attached the results. There are so much memory not deallocated:

select *
from mon$transactions

select *
from mon$memory_usage
select *
from mon$attachments

select *
from mon$statements

select m.*, s.*
from mon$memory_usage m left outer join mon$statements s on (m.mon$stat_id = s.mon$stat_id )

select m.*, t.*
from mon$memory_usage m left outer join mon$transactions t on ( m.mon$stat_id = t.mon$stat_id )

select m.*, a.*
from mon$memory_usage m left outer join mon$attachments a on ( m.mon$stat_id = a.mon$stat_id )

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jun 22, 2011

Modified by: Jesus Angel Garcia Zarco (cointec)

Attachment: fbmemory.rar [ 11972 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jun 22, 2011

Modified by: Jesus Angel Garcia Zarco (cointec)

description: I'm using Firebird 2.5.1.26292 Superserver. The server is running for two weeks and the memory consumption increase daily, but not decrease. I have tested in other enviroment, and all the memory is freed only when all users are disconnected. For know, using Process Explorer from sysinternals, 1326148K of private bytes and 1145716K of Working set, but everyday is increasing between 50 and 100Kb.

After two weeks working, today i have started to have this problem (Operating system call _beginthreadex failed. Error code 8), and i have read that is a problem of memory with server that can not allocate more than 2 Gb. This is because day by day the memory consumption increase, more and more.

If i disconnect all users, fbserver only uses 8 Mb RAM, all memory is released right and start by a memory consumption low, between 200 and 300 Mb, but day by day it increses the momory usage.

I have sent emails attached, with several selects from mon$*, but Alexander Peshkov, can't help anymore because he work only with posix builds. This database structure is used in Firebird 1.0 and Interbase 7-2009 for years without problem.

I only use in my app one UDF and this is the code:

unit UDFMath;

interface

function UDF_power( var Base, Exponent: Double ): double; cdecl; export;
function UDF_sqrt( var Value: double ): double; cdecl; export;

implementation

uses Math;

function UDF_power(var Base, Exponent: Double): double; cdecl;
begin
try
Result := power( Base, Exponent );
except
Result := 0;
end;
end;

function UDF_sqrt( var Value: double ): double; cdecl;
begin
try
Result := sqrt( Value );
except
Result := 0;
end;
end;

initialization
IsMultiThread := True;

end.

=>

I'm using Firebird 2.5.1.26292 Superserver. The server is running for two weeks and the memory consumption increase daily, but not decrease. I have tested in other enviroment, and all the memory is freed only when all users are disconnected. For know, using Process Explorer from sysinternals, 1326148K of private bytes and 1145716K of Working set, but everyday is increasing between 50 and 100Mb.

After two weeks working, today i have started to have this problem (Operating system call _beginthreadex failed. Error code 8), and i have read that is a problem of memory with server that can not allocate more than 2 Gb. This is because day by day the memory consumption increase, more and more.

If i disconnect all users, fbserver only uses 8 Mb RAM, all memory is released right and start by a memory consumption low, between 200 and 300 Mb, but day by day it increses the momory usage.

I have sent emails attached, with several selects from mon$*, but Alexander Peshkov, can't help anymore because he work only with posix builds. This database structure is used in Firebird 1.0 and Interbase 7-2009 for years without problem.

I only use in my app one UDF and this is the code:

unit UDFMath;

interface

function UDF_power( var Base, Exponent: Double ): double; cdecl; export;
function UDF_sqrt( var Value: double ): double; cdecl; export;

implementation

uses Math;

function UDF_power(var Base, Exponent: Double): double; cdecl;
begin
try
Result := power( Base, Exponent );
except
Result := 0;
end;
end;

function UDF_sqrt( var Value: double ): double; cdecl;
begin
try
Result := sqrt( Value );
except
Result := 0;
end;
end;

initialization
IsMultiThread := True;

end.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 5, 2011

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 7, 2011

Commented by: Siva Ramanathan (s2ramana)

This appears to be a very serious issue. Any progress on this?

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 7, 2011

Commented by: Jesus Angel Garcia Zarco (cointec)

I know delelopment team is working on it.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 12, 2011

Commented by: @hvlad

The bug is that at disconnect engine do not released DSQL statements left by application.
Before v2.5 such statements was released by Y-valve. So, we have a regression in v2.5.0.
For 2.5.0 there is a simple workaround - make sure that application released all allocated statements before disconnect.
Note, application should call isc_dsql_free_statement() with DSQL_drop option to completely release statement.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 12, 2011

Commented by: @hvlad

v3 seems not affected as DSQL statements allocated from attachment pool and will die on disconnect with attachment.

In v2.5 DSQL statements are allocated from database pool and left alive until last disconnect (i.e. until database is not released).

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 12, 2011

Modified by: @hvlad

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

resolution: Fixed [ 1 ]

Fix Version: 2.5.1 [ 10333 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 12, 2011

Commented by: Jesus Angel Garcia Zarco (cointec)

I think the workaround is not effective, because there can be disconnections caused by network error, that involve that the memory used by the connection will not be released until all attachments disconnet. After days or months of usage, that memory will be accumulated and when 2 Gb are reached, the engine crush.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jul 12, 2011

Commented by: @hvlad

> I think the workaround is not effective
Nothing is ideal ;)

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Apr 26, 2012

Commented by: Roque (rroque6428)

Hi everyone,

Just to say that this bug is also affecting the following environments:

Linux Ubuntu 11.04 32 bits *and* 64 bits
FirebirdSS-2.5.1.26351-0.i686 *and* FirebirdSS-2.5.1.26351-0.amd64

Memory is only freed on all users disconnection.

Cheers.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Apr 23, 2013

Modified by: @pcisar

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

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 18, 2016

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
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants