> There's no good way to figure out what transaction is being left open,
> and by the time you see the 100% CPU problem, that transaction is
> closed. When it closes, it releases all the garbage it had been
> protecting, and the garbage collection starts eating CPU. However,
> there's usually another factor when you see that level of CPU
> utilization: non-selective indexes. Ordinary garbage collection
> imposes some overhead and will show up in performance. Garbage
> collection on indexes with lots of duplicates will eat your CPU.

But normally the garbage collection should stop after some time. THe
problem, that I have, is that FB never stops using 100% CPU until I
restart the FB-server.

> You can look for indexes with large numbers of duplicates. Run gstat -a
> and pipe the output to a file. In that file, look for the string
> "max dup: " and values > 10000. Drop those indexes and replace them
> with compound indexes that start with the original keys and add a more
> unique segment.

All indexes with max dup > 10000 come from foreign keys and I don't want
to delete the FK, because of the referential integrity.

Regards

Guido