AW: AW: [firebird-support] memory bug?

['Check_Mail' check_m...@satron.de [firebird-support]]

Hello Mark,

 

actually, we use the superserver with this settings. In the past, we had the 
classic server, because only it could access to some more cpu cores. 

 

I thought, when we go back to the classic server, the problem with the 2gb RAM 
overflow is historical, because each of the connection has then an separate 
memory reservation an this should not exceeded the 2gb. I don’t know, why the 
superserver despite the limitation increases to more than 2gb of ram.

 

Thank you..

 

Best regards.

 

Olaf

 

 

Von: firebird-support@yahoogroups.com  
Gesendet: Mittwoch, 28. August 2019 18:02
An: firebird-support@yahoogroups.com
Betreff: Re: AW: [firebird-support] memory bug?

 

  

On 28-8-2019 09:27, 'Check_Mail' check_m...@satron.de 
<mailto:check_m...@satron.de>  [firebird-support] 
wrote:
> 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 update frequency of Firebird isn't really high and I must assume you 
need to plan for downtime anyway for OS updates etc. Firebird 3.0.1 is 
almost 3 years old now (even 3.0.4 is almost one year old by now). 
Upgrading Firebird 3.0.1 to a higher 3.0 version is a drop in 
replacement (no backup and restore is necessary).

Although keeping the client libraries up-to-date is advisable, updating 
the server doesn't require updating your clients at the same time. Older 
Firebird clients (eg from 2.5 or 2.1, in theory even 1.0 although I 
haven't verified that) can also still connect, but you'll need to 
disable wire encryption and make sure that user is created with legacy_auth...

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

Your previous message said you were using SuperServer. Are you using 
ClassicServer instead? That difference is rather important for your problem...

[..]
> Page Size 4096
[..]
> Page buffers 65536
[..]

With SuperServer this is probably fine (256 megabytes per database), 
with ClassicServer or SuperClassic, this requires 256 megabytes per 
connection.

[..]

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

If you are using SuperServer right now, and you want to switch to 
ClassicServer, you should change the page buffer settings of your database.

Mark

-- 
Mark Rotteveel

Re: AW: [firebird-support] memory bug?

[Mark Rotteveel m...@lawinegevaar.nl [firebird-support]]

On 28-8-2019 09:27, 'Check_Mail' check_m...@satron.de [firebird-support] 
wrote:
> 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 update frequency of Firebird isn't really high and I must assume you 
need to plan for downtime anyway for OS updates etc. Firebird 3.0.1 is 
almost 3 years old now (even 3.0.4 is almost one year old by now). 
Upgrading Firebird 3.0.1 to a higher 3.0 version is a drop in 
replacement (no backup and restore is necessary).

Although keeping the client libraries up-to-date is advisable, updating 
the server doesn't require updating your clients at the same time. Older 
Firebird clients (eg from 2.5 or 2.1, in theory even 1.0 although I 
haven't verified that) can also still connect, but you'll need to 
disable wire encryption and make sure that user is created with legacy_auth.

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

Your previous message said you were using SuperServer. Are you using 
ClassicServer instead? That difference is rather important for your problem.

[..]
> Page Size 4096
[..]
> Page buffers 65536
[..]

With SuperServer this is probably fine (256 megabytes per database), 
with ClassicServer or SuperClassic, this requires 256 megabytes per 
connection.

[..]

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

If you are using SuperServer right now, and you want to switch to 
ClassicServer, you should change the page buffer settings of your database.

Mark

-- 
Mark Rotteveel

AW: AW: [firebird-support] memory bug?

['Check_Mail' check_m...@satron.de [firebird-support]]

Hello Karol,

 

first, thank your for your effort.

 

There are zwo databases running on our system, the second one has no open 
transactions, another transactions-model and only just one software were 
connect tot he server.

 

Can the update to the last firebird-version solve this? We had two times now 
this issue, without changing some configurations. Perhaps, the last 
windowsupdates or office updates changes some situations and now this works not 
perfektly. 

 

The transactions-gap is normal, because we uses firebird odbc with ms access 
and the this transactions I cannot affect. All the other clients works fine in 
relation tot he transactions.

 

The storage should be okay, its a vmware one from the newest generation, sas 
hdds, very fast. 

 

The Server OS shows me no warnings or errors. How can I see the content of the 
firebird process? Can I see based on the table stats some indicators, why my 
datbase needs so much memory.

 

If I update to a 64 Bit System, perhaps I dont have this problem anymore. 

 

Thank you.

 

 

Von: firebird-support@yahoogroups.com  
Gesendet: Mittwoch, 28. August 2019 10:16
An: firebird-support@yahoogroups.com
Betreff: Re: AW: [firebird-support] memory bug?

 

  

 

Hi

 

You have buffers set inside database. Your current setting is 256MB ( 

65536×4096) so if this is your only database then Firebird should not eat whole 
memory. But this depend on your sort buffer also.

 

You should look at your system and monitor hardware especially HDD wait.

Also look at transaction management, as you have ~4k transactions gap between 
oldest active and next one.

 

Regards,

Karol Bieniaszewski

Re: AW: [firebird-support] memory bug?

[liviuslivius liviusliv...@poczta.onet.pl [firebird-support]]

HiYou have buffers set inside database. Your current setting is 256MB ( 
65536×4096) so if this is your only database then Firebird should not eat whole 
memory. But this depend on your sort buffer also.You should look at your system 
and monitor hardware especially HDD wait.Also look at transaction management, 
as you have ~4k transactions gap between oldest active and next 
one.Regards,Karol Bieniaszewski
null

AW: [firebird-support] memory bug?

['Check_Mail' check_m...@satron.de [firebird-support]]

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 active29988286

Oldest snapshot29981373

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

Dialect3

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: firebird-support@yahoogroups.com  
Gesendet: Dienstag, 27. August 2019 19:52
An: firebird-support@yahoogroups.com
Betreff: Re: [firebird-support] memory bug?

 

  

On 2019-08-27 14:31, 'Check_Mail' check_m...@satron.de
  
[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

Mark