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

Make faster engine response on cancel\shutdown signals when scanning long list of pointer pages [CORE5727] #5993

Closed
firebird-automations opened this issue Jan 28, 2018 · 9 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @hvlad

Commits: 9bd8685 b0b65ef

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

Tried to reproduce on 65 Gb (oltp-emul) and 500+ gb (real system) databases, repeat two times: with FileSystemCacheThreshold greater than and less than DefaultDBCachePages.
table in bot cases contained about 1600 PP. Linux page cache was flushed and cleared before each run of .sql

On Firebird where this fix was not applied (2.5.7, build: 27086) time of preparing query was very small, less than 700 ms. Can not compare such value with smth other.

Sent several letters to hvlad (last: 05-feb-2018 23:56).

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Currently there is two known cases when engine could not response fast enough on cancel attachment or shutdown signal:
1. when preparing query and evaluating cardinality of huge table with thousands of pointer pages,
2, when sweep looking for data page to cleanup but there is no such data page (after massive load of data, for example).

@firebird-automations
Copy link
Collaborator Author

Commented by: @pavel-zotov

Please, consider also inscrutable behaviour of SIMILAR TO operator.
See, for example, CORE3858

I've repeated again "mistic statement" from there, and all the same: could not get reply from "gfix -shut full -force 0" for ~ 2 minutes on Windows 8.1, recent FB 4.0 build.

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

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

resolution: Fixed [ 1 ]

Fix Version: 4.0 Beta 1 [ 10750 ]

Fix Version: 3.0.4 [ 10863 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Pavel,

CORE3858 have absolutely different reasons.

@firebird-automations
Copy link
Collaborator Author

Commented by: @pavel-zotov

Vlad, i know, of course. I mean: "engine could not response fast enough" - not only of those two reasons that you have mentioned above. Beside very poor performance, changing DB state to full shutdown is impossible during valuable time.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 3.0.3 [ 10810 ]

Fix Version: 3.0.4 [ 10863 ] =>

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Resolved [ 5 ]

QA Status: No test => Cannot be tested

Test Details: Tried to reproduce on 65 Gb (oltp-emul) and 500+ gb (real system) databases, repeat two times: with FileSystemCacheThreshold greater than and less than DefaultDBCachePages.
table in bot cases contained about 1600 PP. Linux page cache was flushed and cleared before each run of .sql

On Firebird where this fix was not applied (2.5.7, build: 27086) time of preparing query was very small, less than 700 ms. Can not compare such value with smth other.

Sent several letters to hvlad (last: 05-feb-2018 23:56).

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Closed [ 6 ]

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