--- In firebird-support@yahoogroups.com, "ochnap2" <ochnap2@y...>
wrote:

> So far so good. The problem is that we are noticing that some hours
> after the cleanup process finishes, the responsiveness of the system
> decays sharply for a while (1-2 hours).

FB don't like mass deletes and updates. The best is to make it in
exlusive connection, when there are not another transactions running,
deactivate indices on this table before cleaning (especially those,
which have many duplicates), make Select from log after cleaning
transaction is commited (this will force garbage collection start),
re-activate indices. If you can't do this in exlusive mode, build your
strategy considering the next: any transaction started before start of
clean and not commited before it's end will prevent collection of
garbage created by it. Any rolled back before clean transaction will
do the same while sweep will not change it's status to commited.
You can look into gstat -h result to check situation with transactions
before and after clean. If oldest transaction after clean is more than
next before clean, you can force garbage collection in log selecting
from it.

> - Is there any way to limit the amount of cpu time that firebird
> consumes?

If you can quickly collect garbage just after clean it will be much
faster and less expensive than under general load.

> or else:
> - Can I choose the moments that the server uses to sweep?

Sweep and garbage collection are different beasts, though alike.
Sweep moves forward oldest transaction (converting rolled back to
commited) and collects garbage as side effect. General garbage
collection is started each time any query encounter clearly unneeded
for any of alive transactions versions. If gap beetwen oldest and next
is large, garbage collection is nearly blocked and when gap will be
minimized server have much work to do, sometimes too much.

Best regards, Alexander.