It is still taking 200MB of RAM. In one hour it increased by alsmost
30MB. There are around on an average 250 connections happen in 4
minutes. They all call stored procedures. Most of them update the
database. This is a multi-threaded application written in C. I am
using the C code generated by Embedded SQL (using gpre, after
removing the 'static' declarations). I have checked, thoroughly, all
the transactions are commited or aborted properly.

Could it be the API I am using ? Should I try using the DSQL APIs ?
How can I change the Page cache and what is the right value ?

Any ideas ??? This is a production system and it has become an
embarrasment for me, because we I had reccommended to use firebird
over the mysql.

Regards:

JS
============================================
Database header page information:
Flags 0
Checksum 12345
Generation 1236012
Page size 4096
ODS version 10.1
Oldest transaction 1235979
Oldest active 1235980
Oldest snapshot 1235980
Next transaction 1236000
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 19
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Jul 28, 2004 10:25:32
Attributes

Variable header data:
*END*




--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

> At 10:45 AM 7/10/2004 +0000, you wrote:
>
>
> >Hi,
> >I have firebird 1.5.1 SS on a custom built linux kernel using Red

Hat

> >9 without NPTL support. When firbird is started, its memory use

shown

> >in the top is very low. But it continously keeps increasing and

goes

> >upto 500MB and even more. Then a point comes, when it stops
> >responding and need to be restarted.
>
> [snip]
>
>
> >=========================
> >Here is the header output:
> >
> >
> >Database header page information:
> > Flags 0
> > Checksum 12345
> > Generation 1162385
> > Page size 4096
> > ODS version 10.1
> > Oldest transaction 1145881
> > Oldest active 1162375
> > Oldest snapshot 1162375
> > Next transaction 1162376
> > Bumped transaction 1
> > Sequence number 0
> > Next attachment ID 0
> > Implementation ID 19
> > Shadow count 0
> > Page buffers 0
> > Next header page 0
> > Database dialect 3
> > Creation date Jul 28, 2004 10:25:32
> > Attributes
> >
> > Variable header data:
> > *END*
> Find and fix the application that is holding read-write

transactions open

> and you are likely to solve all your problems. A gap of nearly

16.500

> between oldest transaction and oldest active [transaction]

represents a

> very huge transaction account in memory, as well as a large amount

of

> uncollected garbage on disk.
>
> Also check that you don't have your page cache set to a size that

is larger

> than is justified by the amount of RAM you have available.
>
> ,/heLen