Subject | Re: [firebird-support] unable to allocate memory exception |
---|---|
Author | unordained |
Post date | 2008-10-10T18:42:51Z |
---------- Original Message -----------
From: "unordained" <unordained_00@...>
To: firebird-support@yahoogroups.com
Sent: Fri, 10 Oct 2008 13:24:49 -0500
Subject: Re: [firebird-support] unable to allocate memory exception
Every temporary blob eats up a page of memory, even for tiny blobs. So my
procedure that updates blob columns from the result of list(), implicitly
casting a varchar to a blob sub_type text, is eating memory.
It just took a while for it to eat enough of the pre-allocated VM size for me
to notice. Once it gets going, it eats about 200kb/s, until it dies.
I'm re-running with the triggers that make this change disabled, to verify the
problem is related to blob assignment.
I'll see about switching those fields back to varchar(5000) or somesuch, to
minimize the impact of updates to them.
-Philip
From: "unordained" <unordained_00@...>
To: firebird-support@yahoogroups.com
Sent: Fri, 10 Oct 2008 13:24:49 -0500
Subject: Re: [firebird-support] unable to allocate memory exception
> > > The exception occures during a commission calculation routine whereAh, crud. I think I see why. http://tracker.firebirdsql.org/browse/CORE-1658
> > > 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?
Every temporary blob eats up a page of memory, even for tiny blobs. So my
procedure that updates blob columns from the result of list(), implicitly
casting a varchar to a blob sub_type text, is eating memory.
It just took a while for it to eat enough of the pre-allocated VM size for me
to notice. Once it gets going, it eats about 200kb/s, until it dies.
I'm re-running with the triggers that make this change disabled, to verify the
problem is related to blob assignment.
I'll see about switching those fields back to varchar(5000) or somesuch, to
minimize the impact of updates to them.
-Philip