Issue Details (XML | Word | Printable)

Key: CORE-3533
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Critical Critical
Assignee: Vlad Khorsun
Reporter: Jesus Angel Garcia Zarco
Votes: 1
Watchers: 3
Operations

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

Firebird memory not released (Using superserver)

Created: 22/Jun/11 08:39 AM   Updated: 23/Apr/13 01:02 PM
Component/s: Engine
Affects Version/s: 2.5.0
Fix Version/s: 2.5.1

Time Tracking:
Not Specified

File Attachments: 1. File fbmemory.rar (40 kB)

Environment: Windows 2003 Server 32 bits

Planning Status: Unspecified


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



 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Jesus Angel Garcia Zarco added a comment - 22/Jun/11 08:42 AM
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 )

Siva Ramanathan added a comment - 07/Jul/11 04:47 PM
This appears to be a very serious issue. Any progress on this?

Jesus Angel Garcia Zarco added a comment - 07/Jul/11 04:56 PM
I know delelopment team is working on it.

Vlad Khorsun added a comment - 12/Jul/11 09:12 AM
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.

Vlad Khorsun added a comment - 12/Jul/11 09:17 AM
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).

Jesus Angel Garcia Zarco added a comment - 12/Jul/11 07:08 PM
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.

Vlad Khorsun added a comment - 12/Jul/11 07:14 PM
> I think the workaround is not effective
Nothing is ideal ;)

Roque added a comment - 26/Apr/12 02:39 PM
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.