---------- Original Message -----------
From: Adriano dos Santos Fernandes <adrianosf@...>
Subject: Re: [firebird-support] Re: unable to allocate memory exception

> > I am using Firebird superserver 2.1.1.17910. All operations are done
> > on one single machine P4 2.8 GHz with 1.5 GB RAM
> >
> > The exception occures during a commission calculation routine where
> > 10 000+ queries are executed (mostly select (65%) but also insert
> > (15%) and update (10%)). The exception occures always between 30 to
> > 60 minutes after start of the routine. We are using beteen 7 and 13
> > connections.
> >
> Do you have BLOBs on the used tables or in variables?
>
> Adriano

Adriano, any particular reason you asked about BLOBs?

I'm running into this issue today, with a very long-running procedure (which
spawns triggers and other procedure calls.) At first (first 10 minutes or so),
it seems that FB's memory usage is stable, but when it fails after about an
hour (and, annoyingly, nearly 99% complete -- I have it logging what it's doing
to file as part of trying to debug this, in a UDF called by the various
procedures and triggers involved, so I can tell it isn't getting stuck, it's
not an infinite-recursion problem, and it's not just one particular row causing
a problem) it's gone up to 2 gigs (reported VM size). The server (SS 2.1.1)
does not crash, and a rollback is enough to release seemingly all the extra
memory. FB goes back down to a VM size of about 40 megs, which is what it was
at when I executed the procedure. It might be off by a k or two, but under the
circumstances, that doesn't seem to matter.

Blobs (all very small sub_type text blobs, but large enough that I wanted to
avoid varchar) are involved in this process; they get updated via calls to list
(...) as rows are modified. It's a parent/child relationship, where triggers on
children cause parents to update their blob columns with a fresh copy of list()
of children; the overall procedure is modifying all children (about 35k
children, about 7k parents.) It's being called from one client (via
FlameRobin), and it's a single "execute procedure", so it doesn't seem to be a
problem with an unclosed Statement object as was the case in this thread
originally.

Is there anything in particular I can do to trace why FB is using so much RAM
all of a sudden? Is it a known problem with BLOBs being updated? I had turned
on the bugcheckabort option this morning, to try to hunt down an actual crash
(which hasn't happened since then), maybe there's another option that would
help me diagnose this?

Thanks,

-Philip