Hi all,

I would like initiate a discussion about current implementation of sweep
thread. Or is it called garbage collection thread ? I'm a little bit
puzzled about the terminology as I saw both GC and sweep thread mentioned
earlier. Anyway, it's not about the sweep performed on whole database,
but about the lower priority thread that works together with worker
threads to remove dead back-versions of rows.

The current implementation of this beast shows a major performance
degradation under heavy load. The heavy load can be caused by many
concurrent users or by few or even one user that performs huge amount of
operations in short time (mass updates, automatic data processing etc.).

As I understand the problem, the performance degradation is caused by
long back-version chains that are not garbage collected because sweep
thread rarely or never wake up. In the past, each worker thread / process
cooperated on garbage collection, so when the back-version chain for
accessed row is evaluated, all dead version are immediately purged. Now,
these version are only marked for sweep thread and left alone. But
because sweep thread fall behind or never get to them, these back-
versions slows down the worker threads, because chain is always evaluated
for dead versions and repeatedly marked for GC. When this chain get long
enough to overflow to next data pages, the whole thing starts to go south
very quickly. To make this problem even worse, it's very easy to achieve
it under normal circumstances and with good database and application
design when you have more than twenty concurrent users, have to operate
in 7x24, single automated batch process with update or delete,
replication, you name it.

Because I have only a vague idea how the GC thread works, I can't say if
this problem affects the Classic architecture, but it definitelly plagued
the Super Server. Also, I have no clue if this could be (at least
partially) solved just by setting the priority for sweep thread at least
to the level of other threads, but as Firebird's get used in more busy
environments, we need to find a solution. Actually, *any* improvement in
GC performance would have a great impact on affected users.

Any ideas ?

Best regards
Pavel Cisar
http://www.ibphoenix.com
For all your upto date Firebird and
InterBase information