Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ISQL sessions finished extremely slow when database moves to SHUTDOWN state (2.5.x only) [CORE5106] #5390

Open
firebird-automations opened this issue Feb 5, 2016 · 2 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @pavel-zotov

Attachments:
gdb-pausing-fb_smp_server-and-fn_lock_print-two-snapshots-with-a-then-with-l__-n-switches.7z
shut-active_25.7z

After database state is moved to shutdown, some of ISQL sessions (which do intensive DML at this moment) can return control to OS extremely slow, elapsed time is measured about 5-7 minutes.
Batch + .sql scripts are in attached .zip.

When this occured, I've ran:
1) gdb (without arguments) for suspending FB process,
2) made two "snapshots" of lock table (with "-a" and "-l -n" swicthes), and finally
3) obtain remaining stacktrace by issuing commands in gdb prompt:

set logging on
set height 0
thread apply all bt

Lock-print data and stack trace see also in attached file.

====== Test Details ======

2do: return to core_5087.fbt and assign there min_version = 2.5.6 after this ticket will be fixed.

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

Attachment: gdb-pausing-fb_smp_server-and-fn_lock_print-two-snapshots-with-_a-then-with_-l__-n-switches.7z [ 12898 ]

Attachment: shut-active_25.7z [ 12899 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Open [ 1 ] => Open [ 1 ]

Test Details: 2do: return to core_5087.fbt and assign there min_version = 2.5.6 after this ticket will be fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant