|Subject||AW: [firebird-support] memory bug?|
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?
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
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.
On 2019-08-27 14:31, 'Check_Mail' check_mail@...
> we are using firebird 3.0.1 Superserver 32 Bit on a Windows ServerFirst, upgrade to 3.0.4 to exclude the possibility that this is caused
> 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.
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