Blocking new connections as a consequence of the too long sweep security2.fdb [CORE5067] #5354
Submitted by: Oleg Matveyev (o_matveev)
Symptoms: every time one process fb_inte_server.exe load 100% CPU one kernel after some easy queries.
WOODY Sun Jan 03 13:34:03 2016
WOODY Sun Jan 03 13:34:06 2016
WOODY Sun Jan 03 13:36:23 2016
WOODY Sun Jan 03 13:36:24 2016
WOODY Sun Jan 03 13:46:27 2016
WOODY Sun Jan 03 13:51:03 2016
Commits: 7a017e6 dc31f92 59e6c1f f2c8f05 76fb404 3553f54 cf5f8a9 FirebirdSQL/fbt-repository@cfa6229 FirebirdSQL/fbt-repository@4902036 FirebirdSQL/fbt-repository@c96b695 FirebirdSQL/fbt-repository@f9fc4be
The text was updated successfully, but these errors were encountered:
Commented by: Oleg Matveyev (o_matveev)
Workaround: backup-restore secirity2.fdb.
But after this operation Oldest transaction always is 1
Commented by: Petr Smach (petr.smach)
I've same problem with 2.5.4 Classic server. (test 2.5.3 and 2.5.5 too, Superserver doesn't have this issue)
Commented by: @hvlad
The issue reason is a bit complex and could be divided into two parts.
2. Slow transaction start.
Commented by: @hvlad
Fix is committed into v2.5.6 and available for testing.
- engine now updates header page with cached transaction counters when last attachment disconnects from database
- algorithm for searching oldest active transaction in TIP cache is improved and now it have complexity O(N) not O(N^2)
- also, engine updates header page with transaction counters just before the sweep - to have refreshed counters values
Commented by: John Franck (bozzy)
Is there any anticipation on the release date for FB 2.5.6?
This issue is giving me (and not only me, I suppose) a lot of problems. With high connection rates, in a month the delta between oldest and next transaction could arise a lot (I'm in the order of 15.000.000).
This value is sufficient to slow down connections by about 10x a clean installation (I have ~20ms connection time with clean security2.fdb, while a month later it's ~180ms). FB is consuming a lot of resources (CPU is often hitting 100%) and this is unacceptable.
The backup/restore workaround implies a downtime, that's not always feasible... BTW, I'm actually having troubles doing so, gbak -se is giving me an error saying it can't write the backup file, despite I'm running as root and the path does exists (I'm on CENTOS 7 x64). By now, the only solution I've found is to overwrite security2.fdb with a clean copy made just after a clean FB installation (I have no users configured).