At 09:42 AM 15/07/2005 -0300, you wrote:

>Hi,
>
>At July 15, 2005, 09:29, Helen Borrie wrote:
>
> > At 09:06 AM 15/07/2005 -0300, Daniel Rail wrote:
>
> >>Firebird is probably trying to do some garbage collection after the
> >>deletes from the table TEXT_REPLACE_ABSTRACT_UPRO, maybe when the
> >>script disconnects from the database and before Firebird unloads the
> >>database from memory.
>
> > "before Firebird unloads the database from memory". Did you really mean to
> > write that?
>
>I should re-read my message more than once.
>
>Let me rephrase that: "before Firebird releases the database after the
>last connection remaining disconnects from it". Is that better?

Yup. But in fact this particular conjecture really doesn't apply here,
since Maurice is running Classic. Classic does cooperative GC, not
idle-time GC as SS does. It will be the next process that hits the table
that cops the GC.

I do agree that the stats point to *sweeps* being needed, possibly quite
often. I would want to get my head around why the sweep threshold is being
reached regularly enough to have sweeps dominating cpu usage. This is
usually gets down to a transaction management problem, i.e. a flaw in the
application code, and is avoidable.

A sweep across a gap of 20,000 or more will take all the cpu cycles the
system will give it. This is OK: the garbage has to be dealt with. But
it will be an excellent plan to seek out the cause and fix it. But I don't
recommend disabling the auto sweep while this problem remains unattended
to. The buildup will tend to progressively slow the machine down as it
occupies more and more transaction inventory space.

Also, like you, I think there is a lot of wasteful processing going on in
this system, especially stuff being pushed unnecessarily over to the client
- with all the concomitant data conversion, buffering, et al., that could
be totally bypassed by a well thought-out server-based processing plan.

./heLen