Subject AW: [firebird-support] memory bug?
Author Check_Mail

Hello Carol and Mark,


in our production environment I cannot simply install every update, it is an 24-hour-running system, I dont like to „touch“ i fit is not absolutely necessary. Okay, I will update the server and all clients soon.


The defaultdbcachepagesize I have not set in this case, I have learned, that is it necessary by using classing Server (set to 75). Or should I change this netzertheless?


Flags           0

Generation  29993102

System Change Number  0

Page Size 4096

Oldest Transaction         29988285

Oldest active        29988286

Oldest snapshot    29981373

Next transaction   29992797

Sequence number 0

Next att. Id          304929

Implementation     HW = Intel/i386 little endian os Windows CC MSVC

Shadow count 0

Page buffers 65536

Next header page 0

Dialect        3

Create date mar 18, 2019 12:39:33

Attributes  force write


Variable header data:

Sweep interval 0


I think, the gap between oldest and next transaction is normal in our case (odbc).


The sweep will be set every night by windows task.


I have check it again, not the oldest is 29.995.544 and the next 30.007.437


I’ve been thinking about the update to a 64 Bit operating system and the 64 Bit Version of firebird (no limitation with 2gb of ram), but some of the applications cannot run on 64 Bit, too old. Although I could run it on a other pc/vmware, but the udfs also runs not on 64 Bit Firebird, freeadhocudf and a self programmed one, very old, without quellcode. Allthough I can change the stored procedures and triggers (replace the udf-functionality with the new given by firebird) , but in my case, I have a lot of work, 200+ stored procedures and many more triggers.


Perhaps it is better to use the classic server, it uses for each connection some ram and a own process.


Thank you.



Von: <>
Gesendet: Dienstag, 27. August 2019 19:52
Betreff: Re: [firebird-support] memory bug?



On 2019-08-27 14:31, 'Check_Mail' check_mail@...
[firebird-support] wrote:

> we are using firebird 3.0.1 Superserver 32 Bit on a Windows Server
> 2008 32 Bit. Currently we have all 60 days the problem, that our
> Applications works not well, the firebird-process uses almost 2GB of
> RAM and this is seemingly the limit of an 32 Bit process. In this
> case, I cannot connect with my tool to see the monitoring tables, no
> new connection can be established.

First, upgrade to 3.0.4 to exclude the possibility that this is caused


by bugs that were fixed 3.0.2, 3.0.3 or 3.0.4.

Also tell use:

- the page size of your database
- the DefaultDbCachePages setting from firebird.conf
- the output of gstat -h on your database